RE: [ubl-ndrsc] Modnamver 7 -- Versioning Clarification

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

Thanks for the review Gunther and Aki.  My responses are inline tagged
<bb/>.

-----Original Message-----
From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com] 
Sent: Wednesday, March 05, 2003 1:03 AM
To: 'ubl-ndrsc@lists.oasis-open.org'
Subject: FW: [ubl-ndrsc] Modnamver 7 -- Versioning Clarification


Hello all,

I gave the Modnamever 7 to a colleague of my. He is working on the SAP's
specifications for namespaces. He gave me the following response.

Kind regards,

	Gunther



Hi Gunther,
here is my feedback on section 13. 

In short, I think it's correct to use immutable namespaces with lexically
structured version information, as the authors recommend (I don't agree with
the use of urn namespaces for someting retrievable, though.)

<bb>
Correct conclusion ;-)
</bb>

In long, XF-1 and XF-2 assume that a namespace may change some definitions
without changing the namespace name nor its associated schemalocation. XF-4
assumes that a namespace may change some definitions by changing its
associated schemalocation. In any case, these options all assume mutable
namespaces (i.e., namespaces change their definitions). Mutable namespaces
have some benefits in a closed environment where we can control both the
client and server sides of the code. Applications can program agaist fixed
namespace names and some minor changes in the definitions within those
namespaces do not break the applications. However, in an open environment,
mutable namespaces will likely break interoperability among systems of
different providers and versions. On the other hand, immutable namespaces
can act as standard contracts in an open environment. However, it can also
break ineroperability if namespace names carry no version information and
applications cannot easily tell the version relationship of one namespace to
another.

Therefor, in the context of UBL, I think immutable namespaces with lexically
structured version information are most appropriate. So, I agree with the
conclusion that the authors make. (I didn't understand the table entry for
XF-3 'con', though.)

Besides the section on versioning, there are several unstated assumptions or
in incorrect or inproper usage of XML related technical terms in the
document. For instance, in the first two paragraphs of Section 3, the
authors are confused with namespaces themselves and how they are used (i.e.
represented as part of QNames) to qualify something in an XML document.
Another confusion is the relationship of validation to namespace
association.

<bb>
I reread those two paragraphs and don't see the problems.  Perhaps that's
because my understanding (or misunderstanding) hasn't changed since I wrote
them.  Here are the offending paragraphs that we might start a new thread on
them if you're so inclined:

Namespaces are a syntactic convenience supporting the association of a
"context" with either a lexical scope (default namespace), or a shorthand
identifier (namespace qualifier).  This context, applied either implicitly
(in a lexical scope) or explicitly (via qualified names) supports
compression of what would otherwise be long identifiers.  In the absence of
namespaces, identifier names are all long.

It is common for an instance document to carry namespace declarations, so
that it might be validated.  Processing logic (such as a stylesheet)
typically carries namespace declarations pertaining to the language in which
it is specified in (XSLT) as well as the namespaces on which it operates.
The latter must match namespaces in the instance document under translation
in order for useful work to be carried out.

</bb>

The first paragraph in section 4.2 (lines 101-104) seems to imply that the
authors assume that if there are N definitions in a namespace, all of these
N definitions should be included in a single (schema) file associated with
this namespace. In other words, there is no partial view to this namespace.
If this is the assumption, it should be clearly stated.

<bb>
Your right all except for the "should" part.  The text is describing a
worst-case alternative that we strive to avoid.  The next paragraph goes on
to state that we should therefore divide UBL into a hierarchy of components.
</bb>

In section 5, the authors describe the associaation of a namespace to some
resource without discussing what they are and if they (or something) should
be made retrievalble. This quesion is crucial to how these namespaces should
be represented. So, the decision taken in section 6 comes out abruptly.

<bb>
The paper doesn't go into the "retrievability" debate.  What's your position
on retrievability?

1. is it important to have a namespace name that starts with "http://"
1.a. if so, is it important that there exist a copy of the schema at the URI
specified by that namespace name?
2. alternatively, in practice, can client software (validating processors
such as parsers) resolve URNs (assuming 1.a. is important).
</bb>

Best regards, Aki

<bb>
Thanks again for your review!
</bb>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>