[
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
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
|
