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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Co-operating with Architectural Forms

[ Lists Home | Date Index | Thread Index ]


Ronald Bourret wrote:

> How rich are the transformations that AFs can perform? Can they do
> anything more than renaming? For example, can they do reordering,
> concatenating, adding/eliminating intermediate structure, etc.?

Architectural processing as defined in the HyTime AFDR appendix
(<URL: http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html >)
can:
	+ rename elements (ArcForm)
	+ rename attributes (ArcNames)
	+ map #PCDATA content to an attribute value (#CONTENT)
	+ map an attribute value to #PCDATA content (#ARCCONT)
	+ "unwrap" elements (ignore the element but process its children)
	+ ignore entire subtrees (ArcSupr)

When used in combination with IMPLICIT LINK, all of these mappings
can be context-sensitive based on ancestor elements (#USELINK)
or previous siblings (#POSTLINK).

(Steve -- does this sound right, or have I missed something?)

It can't map attributes to subelements or subelements to attributes;
to get around this I often define the architectural DTD with both
an attribute and a subelement (with the implied constraint that
they are mutually exclusive), so that client document types can
use whichever one is more convenient.

It can't reorder subelements; best practice is to use the '&' connector
in the architectural DTD when the order doesn't matter (so reordering
isn't needed), or ',' when the order does matter (since reordering
wouldn't be correct).

It can remove intermediate structures (ArcForm #IMPLIED), but can't
introduce intermediate elements.  Again, best practice is to design
the architectural DTD to be "flat", so that (to the extent possible)
the latter is never necessary.

One other note: architectural conformance is defined in terms
of transformation (transform the source document and validate
against the architectural DTD), but in practice architectural
processing usually works more like an Infoset augmentation.
That is, the application works off the original tree, which the
AF processor annotates with architectural information.  This
is critical for things like HyTime -- most of the linking elements
have to be recognized in the context of the source document
to be useful.

One last note -- you don't need to use a full-blown AFDR-compliant
architectural processor to make use of AFs (I almost never do).
You can go a long way just putting #FIXED attributes in the DTD
and writing applications to key off those instead of element type
names.


--Joe English

  jenglish@flightlab.com




 

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

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