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: Datatypes vs anarchy



Michael Champion wrote:
> 
> In my very humble but biased opinion, DOM Level 3 is doing the "right thing"
> in that the content models and validation component is a separate, optional
> module. Implementers can choose to ignore it, and consumers can test for its
> support and either use it, or not use it. Nothing in the rest of the DOM
> depends on the CM module. It is not easy to carve out independent API
> modules from the alleged "layers" of XML-related specs, but the DOM WG tries
> very hard to do so.

This is very important. Thanks.

> In the W3C Schema spec, data types are an integral part of the overall spec
> (the "part 1" and "part 2" distinction does not reflect any explicit
> modularization). The PSVI is not (as far as I can find) explicitly, much
> less modularly, defined.

Very, very true. There are at least three different sets of PSVI
information:

Defaults
Data types
Validation success/failure information

It would be nice if these were explicitly grouped, as it is very easy to
imagine applications that would want one, any two, or all three of
these. In particular, I would like to see processors that take an
instance and a schema and decorate the instance with just defaults or
defaults and data types. When and if people get around to writing such
utilities, modularization would provide predictable levels of service,
rather than having a continuum of implementation levels.

(I've often asked for modularization of the schema features themselves
in the worry that the size and complexity of it is going to lead to a
continuum of implementations, depending on what various applications
actually need. However, there doesn't seem to be much will to do this.)

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