Architectural Forms, A Summary
I've had this rough summary of the AF thread ready in draft for some time now, but Real Life issues have gotten in the way. Rather than let it decay, I thought I'd send it in rough form, collect any comments, and then publish a more structured version when I get time. ---- This is an attempt to distill down the "Co-operating with Architectural Forms" thread to glean some guidance on when Architectural Forms (AFs) are useful, and what they're capable of. * AFs offer a very limited transformation ability, see for detailed summary. Therefore they have a limited functional overlap with XSLT. * AFs promote co-operation between organisations who wish to share data by allowing each organisation to continue to manage it's own vocabulary. Agreement centres on an architectural (or 'meta') schema to which the individual vocabularies can be mapped. Each party retains sovereignty over their own syntax, while having a architectural format to validate other documents against. AFs are useful where there's an agreement on the essential core, but not on non-essential data, or naming. (Also useful internally, e.g. variations across a company) * Because each company provides the mapping from its vocabulary to the architectural form, the work is distributed amongst the co-operating parties. This limits the number of transformations that need to be managed by a single party. * Applications are designed to use the architectural form, and not the specific vocabularies. There is no need to manage local XSLT transforms as each instance document (+/- schema) defines it's own mapping. * Having a common (architectural) format upon which to base processing is more flexible than trying to support multiple input formats (particularly when not all formats can be transformed into one another) * Attribute defaulting makes AFs very simple to use with DTDs * AFs are useful where Format A cannot be properly transformed into Format B, and also where only a subset of either Format A or B is required for a particular process. * An individual schema may reference multiple architectures. This allows data to be re-used in multiple environments. The alternative is to produce data in multiple formats dependent on its expected use. * While AFs can help facilitate co-operation, if there is already a single, or primary vocabulary then there is little additional benefit to be gained from applying them. They're needlessly 'meta'. * A corollary to the above seems to be that if none of the parties attempting to co-operate already has an XML standard, then defining a single vocabulary seems to be a valid starting point. * AFs are also applicable for achieving reuse across horizontal vocabularies (and in this regard appear to directly overlap with the goals for XML Namespaces). For example linking semantics are fairly clear-cut, yet no-one seems keen to have to apply the same names to linking elements. * AFs can be used to map between schemas, but only if the schemas are designed for this, or are very similar. * AFs are primarily a way to indicate that particular elements in different vocabularies share semantics, where the semantics being shared are very general (linking, inclusion, etc). * Neither AFs nor XSLT are true general XML transformation languages. XSLT offer many more transformation features that AFs, however transformation isn't the real aim of AFs. 'Mapping' might be a better way to put it. * An advantage of AFs is that they can be implemented very simply, and work in a streaming mode (e.g. as a SAX Filter). XSLT cannot; however XSLT can also be used to implement architectural mapping, cf APEX * AFs can be used to implement I18N of vocabularies. Mapping element/attribute names to/from their original language. * AFs as originally specified are closely tied to DTDs and Processing Instruction based syntax. However they can be in isolation or in conjunction with another schema language. cf: AFNG * Both Namespaces and AFs are used to associate semantics. Namespaces say "this is an element from the X namespace (e.g. XHTML) and should be processed as such". AFs say "this element is directly equivalent to element Y in architecture B, and should be processed as such". With the caveat that "processed as such" doesn't necessarily require global agreement, but does require local consistency. * Using RDDL, or similar, Namespaces can be made to point directly to a description of these semantics (thin ice here). No such mechanism for AFs, or rather original mechanism used PubId, but there's no standard documentation. * A key premise of AFs is that the GI is only one property of the element that could be used to direct processing. An (architectural) attribute is an equally valid dispatch mechanism. This view allows an element to have multiple types (i.e. be mapped to elements in multiple architectures). This is in some way counter to XML/Namespaces where the GI is the type of the element. The mid-ground seems to be that the GI defines the primary relationship, and that one concedes that (other) attributes can be used to dispatch processing. (cf: role attribute pattern). The real message here is that when we exchange data we agree on how to process it. Using element names is one way. Keying of attributes is another, and also allows me to have separate agreements with another party, but use the same data. Any comments? Cheers, L. -- Leigh Dodds, Research Group, Ingenta | "Pluralitas non est ponenda http://weblogs.userland.com/eclectic | sine necessitate" http://www.xml.com/pub/xmldeviant | -- William of Ockham
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