W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [Widgets] Widget Gallery RSS like sharing format

From: Andrew Welch <andrew.j.welch@gmail.com>
Date: Wed, 18 Mar 2009 10:33:04 +0000
Message-ID: <74a894af0903180333y7c54d084u5fd9963dcdcbf8f9@mail.gmail.com>
To: Marcos Caceres <marcosc@opera.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Robin Berjon <robin@berjon.com>, Thomas Landspurg <thomas.landspurg@gmail.com>, SUZANNE Benoit RD-SIRP-ISS <benoit.suzanne@orange-ftgroup.com>, public-webapps@w3.org
>> I think that is what we are doing. By not including a version
>> identifier, we remove the temptation to make backwards incompatible
>> changes protected by a version switch. Those are the type of changes
>> that are harmful since they require more complex authoring than much
>> of the web seems to use.
> Agreed. Our current model follows Jonas' thinking. We think that our
> approach is architecturally sound but I'm open to hearing further
> suggestions.

It's tricky definitely, and currently I don't think there is an
established way to handle xml versioning, but there are few things to

- never change the namespace, unless you want every existing consumer
of your xml to change too

- when multiple versions of the xml exist, you need some way to
differentiate them other than checking for the existence of certain

If you do use an attribute to identify the intended version of the xml then:

- a 1.0 parser can still parse a 2.0 instance, but give a good error
message when it encounters an instruction it doesn't understand (so
this forward looking behaviour has to be built into the 1.0 parsers).
When a user tries parsing a 2.0 instance using a 1.0 parser, they can
be told "you need a 2.0 parser" rather than "unknown element nnn".

- a 2.0 parser knows all about the 1.0 spec, so can parse both, can
switch modes if there are incompatible changes etc  This allows you to
tweak 1.0 functionality in subsequent versions, rather than having 1.0
instructions set in stone forever (and then having to provide 2.0
alternatives or workarounds etc)

- users/developers/IDEs know exactly what they are dealing with.

That's how XSLT 2.0 does it, and I think XHTML 2.0, but I notice XSD
1.1 is going down a different route...

I guess it's slightly harder here because "version" currently refers
to the widget version, and not the xml version, so you would need to
differentiate them somehow.  Either way, I think an explicit version
is definitely something that you should include (if only in 2.0, with
no version implying 1.0).

Andrew Welch
Kernow: http://kernowforsaxon.sf.net/
Received on Wednesday, 18 March 2009 10:33:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC