[
Lists Home |
Date Index |
Thread Index
]
I prefer to view the stack as an analogy to the OSI networking model,
i.e., not just a conceptual model but also a service model. This makes
it meaningful to speak in terms of a "layer 4 service", "layer 7
service", etc. When you look at it this way, the obvious questions about
each layer are:
- does this layer provide a useful service to the layer it serves?
- does this layer provide a meaningful application service (omitting the
higher layers)?
In that light, layers 5 and 6 need to be switched. XLink depends on
namespaces, not just special names like xml:space.
ID should be in the data augmentation layer.
I question whether an uncomposed tree is useful to any layer or that the
composition layer should conceptually operate in terms of the tree
layer, so I would switch layers 3 and 4, as well.
Then, I question whether the tree layer with raw xmlns declarations is a
desirable service. So I would move the augmented names layer before the
tree layer. I can't see any reason not to put it there, as augmented
names depend only on composed markup.
xml:space="strip" seems to me to be a markup layer operation.
With these comments, the stack would become:
1) Encoding layer. From bits to characters (text)
2) Markup layer. From text to data+markup, xml:space=strip
3) Composition layer. xml:include, xml:base, xlink
4) Property-augmented names layer: non-standard namespaces, RDF
5) Tree layer. From data+markup to attribute-value trees, xml:space=strip
6) Property-augmented data layer: xml:id, ID, xsi:type (simple)
7) Status layer: validation, security
In the reordered stack, the layers 3, 4, 5 and 6 all provide services an
application might reasonably want to use directly, independent of any
higher layers.
BTW, no matter how in bed the implementations of TCP and IP are, IP is a
distinct service that is used, for example, by UDP. In the same way, an
implementation might want validation (when it is done at all) to be in
bed with lower layers. However, if an implementation provided a layer
_service_ the application could be sure no validation would take place.
Bob Foster
http://xmlbuddy.com/
Bullard, Claude L (Len) wrote:
> You are definitely a turtle, Rick. I owe you a drink.
>
> No quibble. The reason for humans on the stack is that they input
> data and receive data, but otherwise, they don't perturbate the stack.
>
> What say the rest of you? Is this stack a good description
> of concepts you use when you design an XML application language?
> If not, should it be?
>
> len
>
> From: Rick Jelliffe [mailto:rjelliffe@allette.com.au]
>
> 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.
|
