[Archive copy mirrored 971002 from the URL: http://home.sprynet.com/sprynet/dmeggins/xml-arch.html; see this canonical/updated version of the document.]
This section develops the example of a simple order document type for online purchasing. In addition to its regular structure, the document uses two base architectures: invoice, containing invoicing information for the supplier, and part-list, containing part information for the customer.
In this example, the document will be processed by a DTD-aware XML
parser (like NXP, MSXML, or SP). All of the architectural information
is contained in the DTD itself, using
declarations for the mappings:
Client DTD (for DTD-aware processing):
<?XML-ArcBase invoice ArcAuto="nArcAuto"?> <?XML-ArcBase part-list ArcAuto="nArcAuto"?> <!ELEMENT order (sender, recipient, item+, price)> <!ELEMENT sender (#PCDATA)> <!ATTLIST sender invoice NUTOKEN #FIXED "customer"> <!ELEMENT recipient (#PCDATA)> <!ATTLIST recipient invoice NUTOKEN #FIXED "customer" part-list NUTOKEN #FIXED "source"> <!ELEMENT item (#PCDATA)> <!ATTLIST item part-list NUTOKEN #FIXED "part" quantity NUTOKEN #REQUIRED partno NUTOKEN #REQUIRED> <!ELEMENT price (#PCDATA)> <!ATTLIST price invoice NUTOKEN #FIXED "billable">
The document itself shows no evidence that you are using architectural forms --- the DTD silently arranges that all valid documents will conform to the two base architectures as well:
Client document (for DTD-aware processing):
<?XML version="1.0"?> <!DOCTYPE order SYSTEM "http://www.acme.com/dtds/order.dtd"> <order> <sender>Wile E. Coyote</sender> <recipient>ACME Parts Inc.</recipient> <item quantity="1" partno="516">Giant slingshot</item> <item quantity="1" partno="18">Electro-magnet</item> <item quantity="1" partno="774">Jet engine</item> <price>USD1,789.57</price> </order>
For XML parsers that are capable only of well-formed parsing (like LARK), mappings must appear as attribute values in the document itself. I have disabled automatic mapping here, but in cases where such an approach makes sense, you will not need to specify all of the mappings explicitly:
Client document (for non-DTD processing):
<?XML version="1.0"?> <?XML-ArcBase invoice ArcAuto="nArcAuto"?> <?XML-ArcBase part-list ArcAuto="nArcAuto"?> <order> <sender invoice="customer">Wile E. Coyote</sender> <recipient invoice="supplier" part-list="source">ACME Parts Inc.</recipient> <item part-list=part quantity="1" partno="516">Giant slingshot</item> <item part-list=part quantity="1" partno="18">Electro-magnet</item> <item part-list=part quantity="1" partno="774">Jet engine</item> <price invoice="billable">USD1,789.57</price> </order>
Note that the root element always maps to the root element of the
base architecture (in this case,
invoice for the
invoice architecture and
part-list for the
part-list architecture), so there is no need to provide an
Normally, processing software will simply note the values of the architectural form attributes rather than actually constructing the architectural documents, but the following two figures show what the above mappings represent conceptually:
Architectural document for invoice base architecture:
<?XML version="1.0"?> <invoice> <customer>Wile E. Coyote</customer> <supplier>ACME Parts Inc.</supplier> <billable>USD1,789.57</billable> </invoice>
Architectural document for part-list base architecture:
<?XML version="1.0"?> <part-list> <source>ACME Parts Inc.</source> <part quantity="1" partno="516">Giant slingshot</part> <part quantity="1" partno="18">Electro-magnet</part> <part quantity="1" partno="774">Jet engine</part> </part-list>
For every XML base architecture, there is a single architecture base declaration, possibly containing architecture support variables for configuration. Then, within the DTD or the document, you use architecture control attributes to perform the actual mappings.
The architecture base declaration is simply a processing
instruction beginning with the string
followed by the name of the base architecture:
You use a separate declaration for each base architecture. If you wish to customise the architectural processing in some way, or to require the use of a meta-DTD for strong validation, you can specify architecture support variables after the base architecture name:
<?XML-ArcBase biblio ArcURL="http://www.w3.org/dtds/biblio.dtd"?>
There are four architecture control attributes that you can use to control mapping within the DTD or document. In many cases, you will need to be concerned only with the architectural form attribute, but the others are available for more complex applications.
ArcFormAarchitecture support variable.
ArcNamrAarchitecture support variable.
ArcSuprAarchitecture support variable.
ArcIgnDAarchitecture support variable.
Within the architecture base declaration, you may specify any the following architecture support variables (the first four configure the architecture control attributes):
ArcURLtakes precedence; if neither is specified, the processing software will not use a meta-DTD).
ArcAuto, automatically map all elements to architectural forms with the same name, unless they have explicit mappings of their own. If the processing software is using the meta-DTD, map only elements with names that appear in the meta-DTD. If the value is
nArcAuto, perform no automatic mapping except for the root element (the default value is
ArcOptvariable given below).
INCLUDEin the meta-DTD (useful only together with