OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.)

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.

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.

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.


Best regards, Aki


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]