[
Lists Home |
Date Index |
Thread Index
]
Whoops. I didn't really mean xml:space=strip to appear the second time.
It's interesting that the reordered layer 4 is approximately what SAX
delivers, while layer 5 is approximately what DOM delivers, in the
absence of validation.
This layering would also put XML general entity resolution in layer 3, I
think.
Bob
Bob Foster wrote:
> 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.
|
