Lark 0.90 available, with an application

Fri Jun 27 16:17:01 BST 1997

At 05:04 PM 6/26/97 -0700, Tim Bray wrote:
>For Xh, I also, after getting it working, realized that I had re-used
>Peter Murray-Rust's trick of just having a .class per element-type
>(Class.forName() and Class.newInstance(), gotta love 'em) - I wonder if
>this is just a coincidence or is this the basic paradigm on which XML 
>software is going to be built?  If so, it might make sense to wire
>a standard class-finder call into XAPI.

It makes sense to have one class per element type (after all, you usually
have distinct types because they have distinct semantics and thus distinct
behavior). You can take this one step further if you add architectures:
your element-type-specific classes can themselves be derived from
arch-form-specific classes.

In other words, given an architecture hierarchy, it should be natural to
define a corresponding implementing class hierarchy.  If your processor has
a fallback scheme for mapping element types to objects that includes
mapping element types to the objects for the architectural forms from which
they are derived when they don't have their own object, it should be
possible to build fairly generic processors for common architectures that
can be quickly applied to new documents simply by adding the architectural
mapping to the documents.

For example, in Tim's case he's mapping to HTML.  It's probably the case
that most of the mapping is a simple one-to-one mapping, which can be
represented by deriving the base document from HTML as an "architecture".[I
say "architecture" because HTML is not really suitable as an architecture
as it is not sufficiently general--in particular, the lack of generic,
nesting divisions with generic titles makes it difficult, if not
impossible, to derive from HTML document types that themselves use
recursive divisions because the mapping to HTML is dependent on the nesting
context.  You could use the SGML implicit LINK feature to do such a
mapping, but I'm not suggesting that as a general solution.]  Not all the
mappings are this simple, but probably 80% are.  Given this, instead of
having one object class per element type in the base documents, you could
have one class per HTML "form" plus unique classes only for those base
elements that require more complex mappings.  If you've got a DTD, you can
do most of the mapping there:

<!ELEMENT Chapter - - (CTitle, Section+) >
<!ATTLIST Chapter
    HTML  NAME  #FIXED "div"
>
<!ELEMENT CTitle   - - (#PCDATA)* >
<!ATTLIST CTitle
   HTML   NAME  #FIXED "h1"
>

Thus, expressed in procedural syntax (I don't know Java), you can have
logic like:

switch (element_type()) {
  case "specialized-A":
     map_specialized_A();
     break;
  case "specialized-B":
     map_specialized_B();
     break;
  default:
    if (if_derived_from_arch(current_node(),"HTML") {
       # Is element derived from the HTML arch?
       switch (arch_form(current_node(),"HTML") {
          case "html":
            print "<html>";
            break;
          case "h1"
            print "<h1>"
          default:
            # no mapping
       }
    }
}

Of course, without a formal mechanism to refer to a hierarchy of
architectures in XML (e.g., using data attributes as defined by the AFDR of
the HyTime standard [review temporarily at
www.drmacro.com/hythtml/clause-A.3.html]), you can only define one level of
architectural inheritance, but that's probably enough to simplify 80% of
the mappings people need to do.

It should be clear as well that browsers can provide easy-to-invoke default
styles by defining an HTML-like architecture that reflects their formatting
semantics and then provide built-in architectural recognition for at least
that architecture (this is essentially what we do when we down-translate to
HTML--we're invoking the browsers' built-in formatting semantics associated
with the HTML "architecture"--but there's no reason the transform can't be
done in the browser.  But note that HTML itself (at least in its current
form) won't work for the reasons given above.

Cheers,

E.

--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)