[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Objections to / uses of PSVI?

• To: xml-dev <xml-dev@l...>
• Subject: Re: Objections to / uses of PSVI?
• From: Ronald Bourret <rpbourret@r...>
• Date: Thu, 16 May 2002 04:56:52 -0700
• References: <3CE193C0.7290457C@r...> <1021421496.2161.6048.camel@l...> <3CE23E39.8E3381F3@r...> <1021464147.17392.6072.camel@l...> <3CE254EA.D98AE254@r...> <542004447693.20020515143847@j...> <3CE378D7.4E43D581@r...> <1702080891303.20020516115252@j...>

Jeni Tennison wrote:
> 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.

I now understand Rick Jelliffe's comment about separating the future
into PSVI and XML worlds.

Assuming the PSVI is read/write (and there is no reason to believe that
it shouldn't be), I can do things like using the DOM to create
schema-less documents with typed nodes. Since serializing this
accurately means (as you point out) serializing the type information,
we've just lost XML.

-- Ron

• Follow-Ups:
  • Re: Objections to / uses of PSVI?
    • From: "W. E. Perry" <wperry@f...>
  • Re: Objections to / uses of PSVI?
    • From: "Simon St.Laurent" <simonstl@s...>

• References:
  • Objections to / uses of PSVI?
    • From: Ronald Bourret <rpbourret@r...>
  • Re: Objections to / uses of PSVI?
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: Objections to / uses of PSVI?
    • From: Ronald Bourret <rpbourret@r...>
  • Re: Objections to / uses of PSVI?
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: Objections to / uses of PSVI?
    • From: Ronald Bourret <rpbourret@r...>
  • Re: Objections to / uses of PSVI?
    • From: Jeni Tennison <jeni@j...>
  • Re: Objections to / uses of PSVI?
    • From: Ronald Bourret <rpbourret@r...>
  • Re: Objections to / uses of PSVI?
    • From: Jeni Tennison <jeni@j...>

• Prev by Date: Re: Rationale Behind The PSVI
• Next by Date: Re: Rationale Behind The PSVI
• Previous by thread: Re: Objections to / uses of PSVI?
• Next by thread: Re: Objections to / uses of PSVI?
• Index(es):
  • Date
  • Thread