[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Lark 0.90 available, with an application
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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|