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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Architectural Forms and XAF

[ Lists Home | Date Index | Thread Index ]
  • From: "Steven R. Newcomb" <srn@techno.com>
  • To: jcowan@reutershealth.com
  • Date: Sun, 5 Mar 2000 00:23:58 -0600


[Steve Newcomb:]
> > Think of the generic identifier as the *value* (not the *name*) of the
> > one-and-only, always-required "nameless" attribute.

[John Cowan:]
> Okay.  Adopting this convention, then, 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.
> 
> 2.  When the nameless attribute is removed, to choose between (a) removing the
>     element entire and (b) replacing it with 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.
> 
> 4.  To validate the result against a chosen DTD (erroneously called
>     the "meta-DTD").
> 
> Is this correct and complete (neglecting features of the SGML data model
> which do not have XML counterparts)?

I think the only major thing you left out was the possibility of
exchanging content with the value of an attribute, and vice versa.

I think your formulation, while correct, could be worded a bit more
understandably, albeit less succinctly.  Here is an attempt to do
that:

  When an architectural-forms-aware XML parser is used in such a way
  as to extract (and optionally validate) an "architectural XML
  instance" from an XML instance that is a client of that architecture,
  the extraction operations of such a parser:

  1.  Will include removing the start tags and end tags of elements
      which are not "architectural", i.e., which are not derived from
      any element type ("architectural form") of that base
      architecture, and which are not, at the option of the author of
      the instance, designated as having to remain for other reasons
      as "bridge" element types, for example because they have unique
      identifiers.  (If uniquely identified elements disappeared
      completely, it might cause the extracted document to be invalid
      because such IDs might be referenced by other elements in the
      extracted instance.)

  2.  Will include changing the generic identifiers of derived
      elements so that the generic identifier of each extracted
      element is the same as the element type name (the "architectural
      form name") of its base element type.  In the case of "bridge"
      elements, their new generic identifier is the bridge form name.
      The original generic identifier of the element is discarded; it
      simply disappears.

  3.  May, at the option of the author of the instance, include
      removing the data content of elements whose start tags and end
      tags are removed per #1, above.

  4.  May, at the option of the author of the instance, include
      renaming attributes and the names of enumerated attribute
      values.

  5.  May, at the option of the author of the instance, exchange
      element content for the value of an attribute, and vice versa.

John, I'd be interested to know why you say that "meta DTD" is an
erroneous (or perhaps misleading?) appellation for DTDs that are used
as the formal expression of the syntactic constraints of base
architectures.  Assuming you're right about that (and I'd have to
guess that, having read your formidable contributions to this list,
you probably are) I'd also be interested to know if you have a better
alternative term for "DTD or other schema used as the formal syntactic
model of a base architecture".

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954
fax    +1 972 517 4571

Suite 211
7101 Chase Oaks Boulevard 
Plano, Texas 75025 USA

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




 

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

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