[
Lists Home |
Date Index |
Thread Index
]
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@flightlab.com
|
