OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Architectural Forms, A Summary

[ Lists Home | Date Index | Thread Index ]

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 

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 

* 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?



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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS