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

Re: Names As Types

• To: Bob Foster <bob@o...>
• Subject: Re: Names As Types
• From: Bob Foster <bob@o...>
• Date: Wed, 31 Aug 2005 12:01:37 -0700
• Cc: "Bullard, Claude L (Len)" <len.bullard@i...>,'Rick Jelliffe' <rjelliffe@a...>,XML Developers List <xml-dev@l...>
• In-reply-to: <4315FAEC.8020909@o...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07207337@h...> <4315FAEC.8020909@o...>
• User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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@a...]
>  >
>  > 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.

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

• Prev by Date: Re: Names As Types
• Next by Date: Re: SV: Names As Types
• Previous by thread: Re: Names As Types
• Next by thread: SAX parser validation with JRE 1.5
• Index(es):
  • Date
  • Thread