Cart
[Home] [By Thread] [By Date] [Recent Entries]
Sean McGrath wrote: > >Architectural processing as defined in the HyTime AFDR appendix > >(<URL: http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html >) > >can: > > + rename elements (ArcForm) > > + rename attributes (ArcNames) > > + map #PCDATA content to an attribute value (#CONTENT) > > + map an attribute value to #PCDATA content (#ARCCONT) > > + "unwrap" elements (ignore the element but process its children) > > + ignore entire subtrees (ArcSupr) > > > >When used in combination with IMPLICIT LINK, all of these mappings > >can be context-sensitive based on ancestor elements (#USELINK) > >or previous siblings (#POSTLINK). > > I'd be interested to know how much of this functionality is > available today in various humble, unassuming, non-meta-infused > tools like XML::Twig for example or XPath based mapping > systems. All of it, but that's comparing apples and screwdrivers :-) The AFDR, if viewed as a transformation language, is extremely lightweight; there's not much you can do with it. Although it could be used to turn a full newsfeed into an RSS channel or DocBook into HTML (but not the kind of HTML you'd want to build a web site out of), it's much more useful as a design tool. The basic idea is, instead of writing software to work on a particular concrete document type, write it as an architectural processor; most of the time this just means keying off of #FIXED attributes instead of element type names. Then it can work with any concrete document type that conforms to the architecture; most of the time this can be accomplished just by adding a few #FIXED attributes to the DTD. Now the HyTime AFDR mechanism is clearly inappropriate for XML, since it relies heavily on DTDs for ease-of-use, but the concepts behind it should be useful. --Joe English jenglish@f...
|
