[
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,
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
|
