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] Formal definition of PSVI (was [xml-dev] Where have the el

[ Lists Home | Date Index | Thread Index ]

 From: "Dare Obasanjo" <kpako@yahoo.com>

> > 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,
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
> the last request?

Caching the PSVI in the client in binary. Probably not even worth doing
caching, given the large size of the PSVI if serialized (though see below
for possible

The PSVI has properties that are not in the XML infoset. Consequently it
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,
   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
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
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

It is very doubtful that there are performance gains in transporting around
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.

Rick Jelliffe
Orlando, Florida


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

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