Lists Home |
Date Index |
> -----Original Message-----
> From: Matthew Gertner [mailto:email@example.com]
> Sent: 27 March 2002 12:01
> To: 'Leigh Dodds'
> Cc: firstname.lastname@example.org
> Subject: Inheritance and Architectural Forms (was RELAX NG Marketing)
There was a recent AF discussion which you may have already seen. I
posted an interim summary here , Robin Cover colllated some of
the additional responses to that summary .
> I believe that you are correct that AFs can handle the kind of polymorphic
> behavior that I have been talking about. There are two problems with this:
> 1) AFs take SGML as gospel and so try to squeeze new features into it with a
> lot of extremely clever but somewhat arcane hacks, making the whole thing a
> kludgy and hard to understand.
John Cowan's Architectural Forms: Next Generation (AF:NG)  attempts to remedy
this. In short: no PI based syntax, separate architectural mapping document
> 2) To get the benefit of AFs you need an AF-aware processor, and I'm not
> aware of such a beast being available to the XML-using masses (but I suspect
> that someone will enlighten me).
I implemented an early version of AF:NG as an XSLT metastylesheet, although
haven't had the time to update it to the latest revision. (willing to share _rough_
code if anyone really wants it)
APEX  also offers an XSLT based approach, but doesn't use AF:NG. Instead the
architectural mapping info is provided an parameters to the stylesheet.
Both of these ought to be easy to slot into an existing processing chain
using XML-Pipeline, a JAXP Transformer filter, or perhaps an alternate
implementation using Streaming Transformations  which could
use a simple SAX filter.
Most of the mystery of AFs seem to come from the difficulty in tackling
the specification, in principle they seem a very simple and intuitive
approach. A good deal of the applications of XSLT I've seen could probably
be handled as mappings.