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

RE: Names As Types

• To: "XML Developers List" <xml-dev@l...>
• Subject: RE: Names As Types
• From: "Rick Jelliffe" <rjelliffe@a...>
• Date: Wed, 31 Aug 2005 12:56:45 +1000 (EST)
• Importance: Normal
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE07207321@h...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07207321@h...>
• User-agent: SquirrelMail/1.4.2

Bullard, Claude L (Len) said:

> What is the ideal XML application language architecture?

Here is how I would like to it to be: a stack defined into
simply describable layers of responsibility. Humans are not the end
of the stack:  they can view any layer and see the inputs, outputs, and
responsibilities of each layer.

In reverse:

1) Encoding layer.  From bits to characters (text)
2) Markup layer. From text to data+markup
3) Tree layer. From data+markup to attribute-value trees, xml:space=strip
4) Composition layer. xml:include, xml:base, xlink
5) Property-augmented data layer: xml:id, xsi:type (simple),
6) Property-augmented names layer: non-standard namespaces, ID, RDF
7) Status layer: validation, security

(These layers are conceptual, not functional, in the same way that
we think of TCP and IP as being separate layers despite their actual
fairly tight coupling.)

This kind of stack provides a alternative to a "processing model"
for XML that lets street uchin specs like xml:include and
even RDF work find a natural home.

The Infoset and PSVI are generalized in four ways:
* a layer (4) to represent composition/linking properties over AVTs,
including building document sets or collections
* a layer (5) to represent a list of properties on data and attribute
values (e.g. datatypes)
* a layer (6) to represent a list of properties on named information items
(elements, attributes)
* a layer (7) to represent status information, in particular kinds of
   validation

This stack, therefore, does not build in any idea that datatyping is a
result of validation. It is fine for XSD to couch itself in those terms,
but XSD is unhelpful for databases in this regard.

Adoption of a conceptual stack like this (by the W3C TAG and XML Core WG
etc.) would, I think, help channel discussion and development. For example,
it would provide a much better model for defining the semantics of xml:lang.
Or for providing an inline specification for non-significant whitespace.
Or for allowing a better RDF.

Cheers
Rick Jelliffe

• References:
  • RE: Names As Types
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>

• Prev by Date: Re: Names As Types
• Next by Date: SV: Substitution Groups - Use 'em or lose 'em?
• Previous by thread: RE: Names As Types
• Next by thread: RE: Names As Types
• Index(es):
  • Date
  • Thread