[
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/
***************************************************************************
|