Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Chris A. <ch...@ma...>]

Matthew Chambers wrote:
> Our version system as I understand it is major.minor.revision. A major 
> or minor change indicates a break in backward compatibility. Thus, 1.0 
> parsers will not be able to read 1.1 files. Strict 1.1 parsers won't be 
> able to read 1.0 files either, but we have tried to avoid making it very 
> hard to support 1.0 from a 1.1 parser.
> 
> The chicken and the egg problem occurs in another place in XML: the 
> encoding. A parser must start reading the file before it can know what 
> encoding it is (e.g. ascii, utf8, utf16, etc.). If it's a truly 
> forward-only stream, that does make things difficult, but dealing with 
> the encoding is much harder than dealing with the schema, so 
> forward-only XML readers probably have a way to deal with the latter if 
> they have a way to deal with the former.

Yep, that's true.  However most XML parsers take care of the encoding 
detection issue behind the scenes (eg. using an internal buffer until 
they see the <?xml?> encoding declaration).  My point was simply that if 
you choose a versioning scheme that will require peering into the file 
first to figure out which schema to use, then readers will have to 
implement some kind of similar dual-parse/buffering mechanism themselves 
which is extra work.

> 
> Like you said, the "schemaLocation" attribute is an optional "hint" - 
> but without a schema, ALL attributes are optional, including the root 
> "version" attribute (not to be confused with the document declaration 
> "version" attribute, another reason not to use it). And the only way to 
> get a schema without the hint from schemaLocation is to get it based on 
> some other hint. Better the official hint than an unofficial one. :)

OK, but from an application perspective it is more reliable to override 
the hints in the document and specify the namespace to XSD location 
mapping yourself (eg. "setExternalSchemaLocation()" in Xerces) because 
the application knows where its schema copies are located, and that 
means it can validate documents even if the schema location hint is 
missing or refers to a location that is not accessible.

With the above approach, you also have the option of avoiding the 
two-pass problem providing that you require that each incompatible 
version of the schema has a unique namespace URI which you can then map 
to different XSD files.

Regards,
Chris