Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] RE: Namespace use cases

From: rjelliffe@-------.---.--
To: "Elliotte Harold" <elharo@-------.--->
Date: 7/14/2009 5:16:00 PM
> On Mon, Jul 13, 2009 at 6:26 PM, Micah
> Dubinko<micah.dubinko@m...> wrote:
>
>> #3 may be a non-issue *for HTML*. One reason why this case gets less
>> attention is that is no consensus exists that using namespaces as a
>> major
>> version number is a best practice (see, for example, the one namespace
>> vs
>> three debates from another era of XHTML)

I think this goes further than the consensus at that time.

> Side note: I think there is consensus on this, and the consensus is
> that it's a bad idea. Consensus was reached on this, if I recall,
> about 10 years ago in the context of XHTML and really hasn't need to
> be revisited since.

I think the consensus at that time was that 1) there is not a one-to-one
correspondence between a namespace and a schema (because some people
wanted to expect that the resource specified by the namespace URI was an
XSD schema) and 2) that just as HTML had several DTDs for the different
dialects, then there certainly could be multiple schemas for the same
namespace.  I think these are reasonable positions; it doesn't impact the
use of namespace changes for incompatible upgrades that go more than being
dialect changes.

For example, in OOXML in many cases percents values have been introduced
where before there were obscurely denominated integer values. Existing
OOXML software will not understand these and will potentially ignore or
strip or wrongly interpret the percentage values. This is not what you
want to happen to your valuable spreadsheet files! So it seems that
changing the namespace to clearly distinguish the new format is an
appropriate approach (though of course it is open to debates about the
particular trade-offs.)

> As long as you're keeping many of the dame elements with the same
> meaning a new namespace doesn't help and is usually actively harmful.
> Only if you're more or less replacing a language with a completely
> different one would a new namespace be appropriate.

I was assuming that when I spoke of a major version it implied some
serious disconnect between the old and the new: I wasn't meaning a
spurious number upgrade for marketing reasons, or upgrades to
fault-tolerant do-your-best systems like HTML.

So I think we actually don't disagree (do we?)

What has changed is that now we have many more important markup languages
whose committees are struggling with how to cope with these major version
upgrades.

Cheers
Rick Jelliffe

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent