Asynch: UnitsML' NS

["Martin S. Weber" <phaeton@sdf-eu.org>]

This is somewhat older stuff which I want to be in the archives of
discussion, ending (imo) the question of how to name the Namespace
for the custom UnitsML. I think we are all consenting to use a
different namespace for UnitsML' and UnitsML.


[note: I'm referring to "custom(ized) UnitsML" as "UnitsML'" herein]

So, on the topic of a choice of namespace for the UnitsML': This
is somewhat outside the scope of the Technical Committee, because
this TC does not handle the issue of namespace naming conventions.
By choosing a given name for the UnitsML' though, a preferred way
of relating to this language, a certain naming convention naturally
emerges.

As I had written/said earlier, IMHO there's no real technical
argument (standards or definitions wise) stating that a specific
Namespace correlates to a specific schema. In contrast, URLs are
not even supposed to resolve!

Nevertheless, common practice, probably from the days of SGML/DTDs
is creating catalogues to resolve external entities describing the
structure of the language -- the schema. This is, together with
"UnitsML is not UnitsML'!" a good argument against naming both
languages have the same namespace.

On the other hand, UnitsML' somewhat _is_ UnitsML. Even though
there exists no way to describe relations like "is a subset of",
or "every valid document of UnitsML' is also a valid document of
UnitsML", this can be "faked" by using the same namespace for both
UnitsML and UnitsML', allowing a full-fledged UnitsML processor to
also process UnitsML' (FSVO "'").

But that brings us back to the problem that was brought up during
the discussion in the TC: If a message cannot round-trip from
A->B->A (with A using UnitsML' and B using UnitsML) then there's
no big use in insisting on the same namespace.  It is going to be
different content on the trip from B to A than A can most likely
handle. Yet it is tagged as being same/compatible content (by the
line of thought of catalogues: (NS -> schema (!)) => (same NS =>
same language)).

By choosing an own namespace we do lose the way to make at least
A think (s)he knows enough of B's language to make A speak to B.
Also B will not be sure whether (s)he understands A. But well,
people will have to insist, and/or insert gateways (of XSLs simply
changing the namespace for example, or stripping invalid UnitsML'
elements) to make it work, but also make it explicit that UnitsML
and UnitsML' are somewhat different...

(Note: If, in a protocol, "B" only answers with elements/attributes
seen from "A" so far, by the way UnitsML' is constructed, "A" will
always understand "B".  -- for those who insist on using the same
namespace(s)).

(Another note, as UnitsML "lite" was changed to be "custom"
UnitsML, after writing UnitsML' all the time as in "UnitsML
derived", I really really like the short and long name of
it :) [UnitsML' = UnitsML derived])

-Martin