OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] PSVI formalization

[ Lists Home | Date Index | Thread Index ]

All this talk of PSVI leads me to ask one question. Who has actually
implemented the PSVI? Sorry, my mistake. I should astart with, who has
implemented the XML infoset? 

You know you hypochondria is really bad when you learn to read your
doctor's writing.
This posting is provided "AS IS" with no warranties, and confers no
You assume all risk for your use. (c) 2002 Microsoft Corporation. All
rights reserved.

> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com] 
> Sent: Thursday, May 09, 2002 8:15 AM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] PSVI formalization
> Recent discussions here about XQuery, XPath 2.0, and their 
> knotted relationships with W3C XML Schema have made me think 
> a fair amount about the relationship between XML and W3C XML 
> Schema, particularly the Post-Schema Validation Infoset 
> (PSVI), more deeply.  
> There were a bunch of presentations last year about how XML + 
> XSD -> XML 2.0, something I found merely annoying then but 
> which makes more sense now.  The community that craves these 
> features is poorly served in many ways by XML 1.0, with its 
> text orientation, structures that can be loose to the edge of 
> complete unpredictability, and a human-readability 
> requirement that is incredibly verbose but useful in many 
> cases only for debugging stages.
> XML 1.0 is now more and more buried under layers of other 
> processing, and the common foundation for W3C work moving 
> forward appears to be the PSVI - or at least an enormous 
> amount of effort is going into integrating the PSVI with a 
> large number of projects, and it seems that most of the 
> vendor and programmer excitement these days is focused on the 
> PSVI, not the brutish markup that lurks underneath.
> The PSVI seems to be what programmers and database folks 
> want.  It offers strongly typed and highly structured 
> information, already guaranteed to conform to their 
> expectations.  It has the same flexible named hierarchies 
> that XML offers, with none of the messy concerns about 
> character encodings, CDATA sections, or the limitations of 
> text for storing binary information.
> At the same time, the PSVI is pretty difficult to express in XML. 
> Layers of type information can make it complex to pin down 
> how best to describe a particular piece of information.  
> Object-oriented development manages that every day, but 
> doesn't have to express the whole hierarchy for every piece 
> of information in a flat representation.  Given recent 
> discussions of synthetic PSVIs, it's not always clear that
> XML+schema->PSVI.
> I'm concluding from all of that that XML is not a good 
> foundation for the kinds of information developers want from 
> the PSVI, and that retrofitting XML to carry that information 
> is perhaps the root cause of the complexity explosion we're 
> seeing in W3C XML Schema and specifications which build on 
> it.  It seems to me that it might be wiser to use the PSVI 
> directly for more abstract information modeling rather than 
> expecting XML representations to carry the load.
> So where does this take us?  Developers who want to work with 
> the PSVI should work with the PSVI, and not worry about XML.  
> The kind of interoperability the PSVI is designed to provide 
> is very different from the kind of interoperability that XML 
> provides - a perfectly reasonable conclusion given the 
> different situations leading to the creation of their 
> respective specifications.
> Beyond that, it seems like some easily-exchanged 
> representation of the PSVI is in order.  XML works, sort of, 
> but it seems pretty obvious that there are better approaches 
> to representing information if you have all the information 
> the PSVI provides rather than a simple "all is text" 
> approach.  This could easily be a binary format, though text 
> might also be an option.
> XML has done a wonderful job of convincing the world that it 
> is possible to agree on base formats for some kinds of 
> information, and that generic tools (parsers, editors, etc.) 
> can be useful for a wide variety of specific problems.  It 
> seems reasonable to suggest that the lesson of XML is not 
> "everyone must use angle brackets and text" but rather that 
> "shared information formats are really useful when supported 
> by a reasonable set of tools".
> Given the immense bias in current XML work at the W3C toward 
> support for the PSVI, it seems like it might well be time to 
> find an appropriate means of expression for the PSVI.  
> Conversions from strongly typed PSVI to loosely typed XML 
> should be trivial, while XML to PSVI should only require a 
> W3C XML Schema (or other PSVI generator) to provide the 
> necessary information.
> PSVI processors could use or extend existing XML 
> infrastructures, replacing only the bottom layer - the parser 
> - and possibly developing its own structures for the layers 
> above.  I suspect that taking the PSVI to its fullest 
> potential is going to involve a lot more work than taking 
> untyped markup to its fullest potential.  It's simply a 
> larger set of problems.
> A binary PSVI format could sure make XML-RPC (PSVI-RPC?) 
> messages a lot smaller.  All it takes is a spec, some free 
> parsers, and some tools. 
> Maybe someday programmers will look back on XML as the 
> bootstrap phase of the PSVI, while the occasional markup geek 
> still pokes around CDATA sections.
> -- 
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS