[
Lists Home |
Date Index |
Thread Index
]
Ron Bourret wrote:
> I think this is an issue during serialization, but (a) there seems
> to be no reason to ever serialize the PSVI, and (b) it is easily
> serializable in the form of the original schema and regenerated
> later.
I'm not sure of either of those, after Evan's posts.
First, I think there are situations when serializing the PSVI is
required. The one that comes to my mind is if you imagine pipelines
that are put together from components *on different machines*. So you
might have a validation service over here to generate a PSVI, and an
XInclude service there, and transformation services here, there and
everywhere.
If we're dealing with a PSVI-aware world, in which transformation
services accept PSVIs and generate PSVIs, then the information that
you pass between these services need to be PSVIs. Assuming that we
don't want to get into RPC, if they're on separate machines, we should
be able to call these services using XML messages of some description,
and get the results as XML as well. That means we need to have
serialized PSVI structures (or structures that can be reconstituted
into PSVIs, which is the same thing).
Second, I think that there will be situations where the PSVI is *not*
easily serializable in the form of the original schema and regenerated
later. As a really basic example from the XQuery WD:
<shoe size="{7}"/>
This creates a shoe element with a size attribute that has a typed
value of the xs:integer 7. This could be generated without a schema
being available. (The other situation, where it's generated with a
schema available, but in which the size attribute has to take a
xs:token, would, I'm sure, be magically prevented through static type
checking.)
So what happens then? You have an XQuery node tree that includes a
size attribute whose value should be interpreted as the xs:integer 7,
and no schema. If you just serialized that as:
<shoe size="7" />
then you'd lose information -- the size attribute would be of the type
xs:anySimpleType in any consequent transformations. So you have to add
schema information somehow to the serialized PSVI, which means
creating a schema based on the observed structure of the document. We
know that's possible (any number of editors do it) but it's not
particularly easy and will add a huge overhead to processors. Plus the
deconstruction/reconstitution method means there's an overhead on the
receiving end as well, when the next service in the pipeline has to
reconstitute the PSVI from the instance and the associated schema.
The other option would be to have a PSVI serialization format that
actually expressed the PSVI in XML (like the one generated by XSV)
rather than trying to use the XML+schema approach. In a perfect world,
parsers encountering XML in the PSVI markup language would generate
exactly the same PSVI from that as they would from the equivalent
XML+schema. Then we could all go around exchanging information in the
PSVI markup language rather than plain old boring XML. I'm only
partially joking.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
