RE: namespaces vs. language versions

Larry Masinter writes:

> It is pretty clear to me given the fairly broad definition of “version”
> as it applies to language-as-used, language-as-specified that multiple
> ‘versions’ of an XML-based language might share the same namespace,
> and that therefore the “namespace” alone could not serve as the
> sole indicator of version. On the other hand, two languages which
> use different namespaces are different languages, clearly.

> I agree with your conclusion, but even this formulation tends, if 
> indirectly, to promote the myth that "the namespace" can be identified, at 
> least for a given version of a language. 

I'm not sure "myth" is the right word. If namespaces are vocabularies,
then a "language" (whether language-as-used or language-as-specified)
has associated with it one or more vocabularies.

> It's not just that "multiple 
> versions...might share a namespace"; even a single "version" of a language 
> might be built of markup from many namespaces, and that markup in turn 
> might be used in other nearly unrelated languages.

Here is an analogy: If a bilingual community engages in
a conversation, they might converse using a hybrid of the two
languages they share. The hybrid itself is a kind of "language",
which has a vocabulary consisting of words from both of the
constituent languages.  The hybrid language might even, in
some circumstances, have meanings or usage rules which are
not directly inherited from either.

In that sense, XML with namespaces provides a mechanism for
creating hybrid languages which use many namespaces. The 
hybrids themselves evolve over time.

> Example:  ...

(good example)


> For any one document type, there will be a root element, and if we believe 
> in the TAG's (incomplete) work on XML Functions [1] (ISSUE-34 [2]), the 
> documentation for that root element will determine the meaning in context, 
> and thus the "versioning rules"  of the subelements it uses, regardless of 
> namespace.  

I'm not familiar with this work, and the cited documents aren't
enough for me to quite get it. I don't understand the
"documentation for [that] root element" insofar as what the
relationship might be between the "documentation" for a root
element and the languages and their versions which allow that
(namespaced) root element as their root -- what is the scope
of the documentation, how would the documentation evolve, etc.?



> Of course, it would in many cases (though not all, IMO) be a 
> good thing if the documentation for a root element <orders:purchaseOrder> 
> delegated to the documentation for its children <shipping:label> as to how 
> that subelement may change with versioning. 

There is certainly an issue of "who is on top"; I can see how
it is possible to define a "language" for purchase orders
to define or constrain the interpretation and versioning rules
for shipping labels, but I would argue that it is *not*
a good thing, from a design point of view.

An *application* which is built using the purchase order language
with instances of the shipping label language within *should* 
define the versions of purchase orders and shipping labels
that interoperable implementations (at any point in time) should
use; such a set of requirements might form a useful applicability
statement which would aid in building interoperable implementations.

However, those rules are not *language* constraints, or at least,
they should not be. This is part of the orthogonality principle:
the languages should be allowed to evolve independently.

Combining language definition with interoperability applicability
statements is one of the major flaws of the current HTML5 document.


> So in this example, the 
> <billing:purchaseOrder> documentation could say "A <shipping:label> 
> element specifies the label to be printed for shipping the order;  future 
> versions of <shipping:label> are supported insofar as these are properly 
> documented in (future versions of) the specification for 
> <shipping:label>".  

This kind of statement in standards leads to serious difficulties
(I'll have to search to find some examples.), because it attempts
to predict or constrain, in one document, the future evolution path
of another for which it is not normative.

> Or, the documentation for <billing:purchaseOrder> 
> could say:  "A <shipping:label> element specifies the label to be printed 
> for shipping the order, and the contents are to be interpreted per the 1 
> January 1999 version of the specification for <shipping:label>; later 
> versions of that specification are not allowed by this version of the 
> <billing:purchaseOrder> specification."

Yes, you could say that, but again, I think it is unfortunate and
not the preferred path. 

> In short, I want to try and convince everyone that namespaces are pretty 
> much orthogonal to the whole versioning discussion.  

I argue the complete opposite: getting clarity on how specific
languages can evolve independently, including those which are
distinguished by namespaces, root elements, and version indicators
of those root elements, is a very important aspect of "the
whole versioning discussion".

Otherwise, we will see HTML redefining RDFa and SVG and any other
language, or inappropriately constraining the versioning of 
included subsets.

> What matters in XML 
> are tag names and their (potentially evolving) specifications.  For 
> documents, versions and namespaces, it's pretty much mix-n-match in the 
> general case.  So, I think we should be careful about referring to "the 
> namespace", even for a particular version.

I'm a big fan of being careful, and I admit my original posting
about "the" namespace left out discussion of the very common case
of hybrid languages build out of sublanguages in multiple namespaces,
where each sublanguage evolves independently, and there are also
some idioms of usage which assign special meanings to combinations.


[1] http://www.w3.org/2001/tag/doc/elabInfoset-20071127/elabInfoset.html  
[2] http://www.w3.org/2001/tag/group/track/issues/34

 



Larry Masinter <masinter@adobe.com>
Sent by: www-tag-request@w3.org
08/05/2009 05:00 PM
 
        To:     "www-tag@w3.org" <www-tag@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        namespaces vs. language versions


I think I still had an action item on the HTML working group to insure
that the versioning document touched on the relationship of namespaces
to language versions.
 
It is pretty clear to me given the fairly broad definition of “version”
as it applies to language-as-used, language-as-specified that multiple
‘versions’ of an XML-based language might share the same namespace,
and that therefore the “namespace” alone could not serve as the
sole indicator of version. On the other hand, two languages which
use different namespaces are different languages, clearly.
 
I’m not sure if there is general advice about when new namespaces
SHOULD be used when defining a new language version/variant,
except to point out that changing namespaces can have bad
backward compatibility issues.
 
Larry
--
http://larry.masinter.net

Received on Saturday, 8 August 2009 10:39:33 UTC