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

Re: Architectural Forms and XAF

• From: Arjun Ray <aray@q...>
• To: "xml-dev@x..." <xml-dev@x...>
• Date: Sat, 4 Mar 2000 00:10:34 -0500 (EST)

On Fri, 3 Mar 2000, John Cowan wrote:

> [...] architectural processors have the following capabilities
> (without regard to how they are expressed):
> 
> 1.  To rename or remove any attribute of an element, including the
>     nameless attribute.

It might look like that, but "renaming or removing" is a potentially
confusing description.  The "game" is filling a template ("where do I
get this?  where do I get that?")

If the #GI of an element in the architectural instance corresponds to
the value of the foo attribute in the original instance, one could
*say* that the original nameless attribute has been "removed" and the
foo attribute has been "renamed" to the namless one, but this tends to
suggest that the process is one of iterating through the complete list
of "client" attributes, deciding what to do with each one.  

It's actually the other way around - iterating through the list of
attributes in the architectural instance, and for each one deciding
how to "assign" its value.  Starting the whole process off is a matter
of examining particular attributes in the client instance - mainly to
identify the architectural #GI first (for obvious reasons.)

> 2.  When the nameless attribute is removed, to choose between 
>     (a) removing the element entire and 
>     (b) replacing it with its content.

Or some part of its content.

> 3.  To do these things conditionally on 
>     (a) the original generic identifier of the element or 
>     (b) the presence or absence of an ID attribute.

The original generic identifier is never a determining factor in and
of itself.  

Elements with ID attributes are automatically mapped in order to
preserve the integrity of architectural elements with IDREF
attributes.  This is actually a very sticky business, and might
benefit from rethinking.  The current rule may be the "simplest".

> 4.  To validate the result against a chosen DTD (erroneously
>     called the "meta-DTD").

This is done as a matter of course, but there's more to it.  With
defaulting, we have the old SGML problem of inextricably entwining
parsing and validation (e.g. content models for their predictive
value.)  This too might benefit from rethinking.

> Is this correct and complete (neglecting features of the SGML data
> model which do not have XML counterparts)?

Correct, technically yes; complete, no.  A canonical reference (as far
as the Web is concerned) exists:

  http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html

The essential mechanics are covered in the description of cotnrol
attributes:

  http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.5.html
 
While AFs can be used for transformations, explicit transformations
aren't really the intent.  I find "extraction" a better term.  An AF
processor could work like a filter, e.g. as a SAX interface layered on
top of a SAX interface to the original document: the application gets
informed of SAX events according to the architectural instance (DTD)
rather than the original.

The things left out of the description above are the control
attributes that are "non-local" or "stateful" for an AF processor:

  1.  ArcAuto:  whether the original #GI is a default.
  2.  ArcSupr:  Conditional or absolute suppression of architectural
                processing of sub-elements.
  3.  ArcIgnD:  Treatment of data content. 

(Ad (3), it is possible that an attribute of the architectural element
gets its value from the syntactic data content of the client element,
but if the architectural element has a model allowing #PCDATA, this
"mapping" of the data content to an attribute does *not* inhibit
architectural data content.  Turning that "off" needs the ArcIgnD
control.  This is an example of why it's wrong to think in terms of
'what to do with the pieces in the client'.)


Arjun



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• References:
  • Re: Architectural Forms and XAF
    • From: John Cowan <jcowan@r...>

• Prev by Date: Re: XLink - Assert linking relationships among more than two resource s
• Next by Date: Call for Participation - Extreme Markup Languages
• Previous by thread: Re: Architectural Forms and XAF
• Next by thread: Re: Architectural Forms and XAF
• Index(es):
  • Date
  • Thread