W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2000

Re: LC-185 comments from XML Core WG

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Mon, 09 Oct 2000 00:23:12 -0600
Message-Id: <>
To: Paul Grosso <pgrosso@arbortext.com>
Cc: w3c-xml-core-wg@w3.org, W3C XML Schema Comments list <www-xml-schema-comments@w3.org>
At 2000-10-08 10:00, Paul Grosso wrote:
>It is not clear to me whether the creation of the PSV is seen as a process
>that augments the existing infoset or as a process of creating a completely
>new infoset.

If you cannot step twice into the same river, I suppose one could
say it's a new infoset which just happens to be a proper superset of the
old one.  And I doubt that the spec actually commits itself, one way
or the other.  But for what it's worth, here's one WG member who
believes the simplest way to view it is that the PSV infoset augments
the pre-validation infoset by adding new information items and some
new properties to old information items.  (I don't think the spec
says "thou shalt pass the pre-schema-validation infoset through
to your downstream apps", but it would be crazy not to do so.)

>I'm not sure what a 'component' is, but I gather that the PSV infoset
>is expected to augment the pre-SV infoset with (schema-specific) infoitems
>each with various properties.


>Depending on just how this is done, this
>might mean that things that were children of a given infoitem might become

I believe this never happens.  No existing properties are changed
(we thought about changing/updating the 'normalized value' property of
attributes, but decided against it on the advice of various people
including members of Core, DOM, and Query).

>In the least, it appears to imply that infoitems that had
>a "next/previous sibling" relationship would now have another infoitem in
>between.  Such changes to the structure of the tree must be considered in
>light of XPath like addressing into the infoset.
>If the PSV creation is more of an "augmentation" and things like XPointer,
>XSLT, or anything else that uses XPath or a DOM API or some similar 
>notation to address into the original document's infoset are expected to
>continue to work unaltered on the PSV infoset, then the addition of infoitems
>throughout the tree (as opposed to just new properties on existing infoitems
>[which properties could perhaps be "references" to one or more infoitems]
>or addition of infoitems "outside" the tree [e.g., in the infoset but not
>descendants of the document's root element]) will require new "axes"
>(to use the XPath terminology) to allow access to the new infoitems while
>allowing existing addresses to continue to work.

Yes; the XSL and XML Query WGs are beginning to consider how to extend
XPath to deal with datatypes, and adding some new axes is one direction
I think people are thinking about.

>Has the XML Schema work addressed these issues?

Yes.  One of the reasons we have added info items and properties,
instead of changing existing properties, is to help ensure that
it won't break things if an XML Schema processor is inserted upstream
from an application that uses or supports XPaths.

-C. M. Sperberg-McQueen
  Co-chair, W3C XML Schema WG 
Received on Sunday, 8 October 2000 20:37:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:49 UTC