- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Mon, 09 Oct 2000 00:23:12 -0600
- 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. Yes. >Depending on just how this is done, this >might mean that things that were children of a given infoitem might become >grandchildren. 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 >tree-based >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