[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


formal definition for pi
 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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.