OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] PSVI using existing infoset items

Jeni Tennison wrote:

> Hi Eric,
>>There would, of course, be a balance to search between verbosity and
> The other thing that you/we should think about is the ways in which

"you/we" ? I would be happy to co-edit such a specification as a 
collaborative effort on xml-dev (such as it has been done before for 
DDML, SAX or RDDL to name few) if there is enough interest for the idea.

> people will use this PSVI-annotated XML structure and the kind of PSVI
> information that will need to get.

Definitely. I have rushed into angle brackets to give a concreate example, 

but the objectives should be defined first.

I think that the main ones should be:

- simple to read
- simple to process, ie:
   - as transparent as possible for XSLT and XPath
   - easy to filter out for SAX and DOM and alike applications
- schema independent
- carry the "significant" information from DTD and W3C XML
   Schema PSVI (which are the 2 schema languages currently

> As an illustration, one big requirement that springs to mind is easy
> access to information about the type definition hierarchy, so that you
> could work out easily not only that the Price element has the type
> PriceType, but also that PriceType is an extension of xs:decimal so
> the content of the Price element is an xs:decimal.
> Possibilities I can think of are:
>  - use ids/references to link between a type and its base type
>  - record a space-separated list of the types on a particular
>    element/attribute
>  - use nesting to encode the hierarchical organisation of the types
> I think the latter is probably the best method for the particular
> requirement, certainly it's the most open to access through XPath 1.0.
> Also, having the type definitions separate from the instances of
> elements and attributes means that the PSVI XML is less verbose than
> it would be if they were repeated all the time.
> Another thing that might be worth considering is the possibility of
> making the schema information set into a separate document from the
> PSVI of a particular instance. The schema information set XML (i.e.
> all the element/attribute declarations and type definitions) could be
> generated once per schema, whereas the PSVI XML would be generated for
> each individual instance. The PSVI XML could reference the schema
> information set XML to get access to things like the type definition
> hierarchy, annotations and the other static stuff.
> It would also be a lot easier for a schema validator to handle the
> schema information set XML than it would to handle the original schema
> because they wouldn't have to worry about all the XML Representation
> of Schemas constraints (Henry T. reported on XSL-List that the XML
> Representation of Schemas constraints takes up 2/3 of the code of
> XSV).

I am wondering if the problem couldn't be split into two more manageable 

1) The XML PSVI itself
2) A need for a "canonical" representation of W3C XML Schema which would 
be easier to process by applications.

Also, the canonical representation could include IDs for all its 
components (which are optional in a schema) and the PSVI could easily 
link into the canonical schema.

The XML PSVI would then include only the most "important" (and most 
schema independent) items and the canonical schema be the exhaustive 

This should answer to both the concern of Simon who doesn't want to have 
to look into a schema and yours who would like to get exhaustive 
insights of the schema.

In my first example, I had included the primitive datatypes since, for 
W3C XML Schema datatypes, the core "semantic" of a type is identified by 
its primitive type and it's probably something we would like in the XML 

Thanks for your detailed answer!


> Just some thoughts,
> Jeni
> ---
> Jeni Tennison
> http://www.jenitennison.com/

Rendez-vous  Paris pour le Forum XML.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org