Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Formal definition of PSVI (was Where have the el
 From: "Dare Obasanjo" <kpako@y...> > > Otherwise, if you want to see angle brackets, Richard Tobin and Henry > > Thompson have published a "a first cut at an XML serialisation of the > > (PSV) Infoset" which is non normative but gives a more concrete idea of > > what the beast looks like: > > > > http://www.w3.org/2001/05/serialized-infoset-schema.html It is important to realize that this "serialization" of the PSVI is actually the tranformation of a PSVI to a vanilla infoset: so if you parse it as XML into an infoset, you then need to run some kind of transformation on it to get back the original PSVI, assuming that the PSVI was originally represented using an extended DOM. > So what exactly is the consesus opinion of the W3C or members of xml-dev as to > how the PSVI data of a document is attached to it to avoid revalidation on > subsequent requests for PSVI data if the document has not been modified since > the last request? Caching the PSVI in the client in binary. Probably not even worth doing persistent caching, given the large size of the PSVI if serialized (though see below for possible ways.) The PSVI has properties that are not in the XML infoset. Consequently it cannot be serialized directly out (i.e. as just attributes and elements which maintain the infoset attribute-and-element relations.). There are only three choices (leaving aside the choice of decorating the infoset with new attributes, a la architectural forms): 1) revalidate with the schema 2) generate the infoset augmentations as the form of a large link base, transmited out-of-band 3) make up some PI convention So the PSVI is not XML. It is an augmented version of the XML infoset which has no direct serializarion into XML. In the absense of any any of the above, there is no way for PSVI data to be transported around in a way that existing XML applications can continue using the XML infoset and make use of the PSVI augmentations: the model is that the data must be revalidated at each parse, and then processes which want to avoid revalidation must be tightly coupled and pass each other PSVI data structures (such as augmented DOMs, or Richard & Henry's document type.) It is very doubtful that there are performance gains in transporting around a PSVI-in-XML such as Richard & Henry's document type, rather than revalidating the document. A PSVI DOM only requires that the type reference in the node point to a different location, so should be just as efficent as a conventional DOM AFAIK. Richard & Henry's PSVI document type is good for debugging, teaching, testing implementations, but I doubt if they would propose it as a notation for data transport, caching and storage. Cheers Rick Jelliffe Topologi, Orlando, Florida 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
