[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Co-operating with Architectural Forms

• To: xml-dev <xml-dev@l...>
• Subject: Re: Co-operating with Architectural Forms
• From: Joe English <jenglish@f...>
• Date: Thu, 31 Jan 2002 08:18:34 -0800
• In-reply-to: <3C58F0CA.C6D43D92@r...>
• References: <3C58F0CA.C6D43D92@r...> <NCBBKFMJCLIMOBIGKFMJMEAIHCAA.ldodds@i...> <200201301936.g0UJaOj12628@d...>

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@f...

• Follow-Ups:
  • Re: Co-operating with Architectural Forms
    • From: Sean McGrath <sean.mcgrath@p...>

• References:
  • Re: Co-operating with Architectural Forms
    • From: Ronald Bourret <rpbourret@r...>
  • Co-operating with Architectural Forms
    • From: "Leigh Dodds" <ldodds@i...>
  • Re: Co-operating with Architectural Forms
    • From: Joe English <jenglish@f...>

• Prev by Date: Re: There is a meaning, but it's not in the data alone
• Next by Date: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• Previous by thread: Re: Co-operating with Architectural Forms
• Next by thread: Re: Co-operating with Architectural Forms
• Index(es):
  • Date
  • Thread