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: PSVI



Rick Jelliffe wrote:
> 
> There are four or so basic choices (non-exclusive) for what a Schema
> language can do:
> 
> -- transform the document, leaving the original in place: e.g. report
> Boolean valid, generate a set of links, pretty-print the document, generate
> code for interfaces
> 
> -- provide type information for programs accessing the infoset, and allow
> optimized infosets to be built: e.g. so that a query on a number stores the
> query value in an int rather than a string, and uses number-based
> comparisons not text-based
> 
>  -- augment the infoset using the existing categories: e.g. the defaults in
> a DTD add special attribute values, but the fact of whether the attribute
> values were specified or defaulted or are fixed makes no difference to the
> normal API. (This augmentation could be implemented by lookup rather than
> inline if there is a 1-1 correspondence between node name and type. Even if
> there is no a 1-1 correspondence, the defaulting etc would usually not be
> explicit but implemented by pointing to a singleton representing the
> appropriate markup declarations.)
> 
>  -- augment the infoset with new kinds of information which do not
> correspond to any XML markup: e.g. allow nodes to have properties or types
> or facets, allow individual nodes to have validity status (or other
> outcomes) added per node, allow extra nodes corresponding to a data value
> after it has been normalized and put into some optimized form such as an
> array of int. (This augmentation could be implemented by lookup rather than
> inline if there is a 1-1 correspondence between node name and type. Even if
> there is no a 1-1 correspondence, the defaulting etc would usually not be
> explicit but implemented by pointing to a singleton representing the
> appropriate markup declarations.)

I think one of the things that this points out is that the PSVI doesn't
necessarily have to do with validation. That is, some of the information
in the PSVI -- especially default values and data types -- is orthogonal
to validation.

This is one of the things that bothers me about the PSVI. My reading of
the spec is that it is an all or nothing thing. I'm also guessing that
it is likely to be implemented this way.

But what if I want things like attribute defaults or data types but
don't care about validation? Can I get these? It doesn't look like it.
My fear is that we're going to end up with what we did in XML 1.0 with
respect to the feature sets of parsers. That is, instead of having
well-defined feature categories, we have a continuum of features from
parsing well-formed documents only to full validation.

The practical result of this is that you only have two choices in an XML
1.0 application: (1) assume minimal functionality and put all other
information in the application or (2) always use validation. As an
example of this, my software works in closed systems, so it is
reasonable to omit validation and enjoy slightly faster processing. But
I can't trust that the parser will add attribute default values to a
document. Therefore, I have to hardcode those defaults in the
application.

It would be nice if the PSVI was factored into multiple categories (e.g.
defaults, type information, validation information) and parsers could
implement these separately, with applications choosing what they needed.

-- 
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com