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


Help: OASIS Mailing Lists Help | MarkMail Help

legaldocml message

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

Subject: Making my case for keeping the AKN namespace URI as is --- forever.

I believe we have no choice but to keep the current XML namespace URI for Akoma Ntoso. XML namespaces are a fairly crude mechanism for distinguishing names from one schema to another. Iâve never seen a mechanism for evolving namespaces or managing versions using the namespace URI. If there was a thought out namespace versioning mechanism or some sort of provision for wildcarding or parameterizing namespaces, it would be a different matter â but there isnât.


There is no explicit relationship between namespaces. The namespace http://www.w3.org/1999/xhtml is just as related to http://docs.oasis-open.org/legaldocml/ns/akn/3.0 as http://docs.oasis-open.org/legaldocml/ns/akn/3.1 is. Even though the difference in the last two namespace URIs is just one digit, a document in one namespace shares no explicit relationship to documents from the other, despite the incredibly strong similarity in the tags.


I think we shoot ourselves in the foot (or maybe the head) when we change namespace URIs. Any dream of interoperability gets completely lost. A vast worldwide corpus of documents all using Akoma Ntoso will inherently be divided into clusters of different namespaces sharing no intrinsic interoperability. And tools built for one namespace wonât work with tools from the other namespace unless the tool developer agrees to maintain different code sets for each namespace â something that is quite a burden.


Customers wonât build any confidence in the schema if it appears that it is subject to breaking changes (and changing the namespace URI is a breaking change) every time there is a revision. Customers are extremely resistant to changes â especially when those changes donât provide any additional value to them. Supporting contract documents probably will be of little value to anyone within the legislative community, so a different namespace will be of no interest and they will elect to stay where they are with the existing namespace. As a product vendor, weâre obliged to support our customers for a very long time. In the case of California, weâve been supporting code we deployed 14 years ago â and theyâve only just migrated from Windows XP to Windows 7 in the past few months. Weâre not equipped or funded to support product variants forced by a namespace URI change.


While itâs fairly easy to parameterize namespaces within programming code (and Iâve done that in my _javascript_), itâs not nearly as easy in other places like instance documents, CSS files, XSLT files, other XML files, and on an on. In my current implementation of the LegisPro editor, Iâve parameterized the namespace as much as I possibly can. However, the namespace URI is still found in 281 different places. For customers, this problem is much bigger. Once they publish their documents in Akoma Ntoso, possibly in the 10âs of thousands, they wonât want to republish those again for the sake of a namespace URI change. And their customers downstream will be very upset if their dependence on published data gets upended by a namespace URI change â and so on and so on. The more successful adoption is, the more intractable a namespace URI change becomes.


For Akoma Ntoso to gain a following, it must be viewed as a very stable rock solid base to build upon. A namespace URI change is an earthquake â it unravels interoperability. Itâs a breaking change and it creates clusters of similar but unrelated documents all of which claim to be Akoma Ntoso, but which arenât usable from one namespace to another.


Weâre not the first ones to face this dilemma, so we should learn from others:

The HTML 4 namespace is: http://www.w3.org/1999/xhtml

The HTML 5 namespace (for XHTML compatibility) is: http://www.w3.org/1999/xhtml (differentiated by DocType)


The XSD 1.0 namespace is: http://www.w3.org/2001/XMLSchema

The XSD 1.1 namespace is: http://www.w3.org/2001/XMLSchema


The XSLT 1.0 namespace is: http://www.w3.org/1999/XSL/Transform.

The XSLT 2.0 namespace is: http://www.w3.org/1999/XSL/Transform (differentiated by @version attribute)


The DocBook 4.X (XML) namespace is:Â http://docbook.org/ns/docbook

The DocBook 5.X namespace is http://docbook.org/ns/docbook (differentiated by @version attribute)

â Note: DocBook is an OASIS schema and DocBook 5 is not totally backwards compatible with DocBook 4.X â yet the namespace is unchanged


The DITA 1.1 namespace is http://dita.oasis-open.org/architecture/2005/

The DITA 1.2 namespace is http://dita.oasis-open.org/architecture/2005/ (differentiated by @DITAArchVersion attribute)

â Note: The OASIS spec for DITA includes this: âIt is the intent of the OASIS DITA Technical Committee that the DITA namespace URI will not change arbitrarily with each subsequent revision of the corresponding WSDL or XML Schema documents but rather change only when a subsequent revision, published in conjunction with a Committee Draft, results in non-backwardly compatible changes from a previously published Committee Draft.â

  • ÂÂÂÂÂ DITAâs use of namespaces seems weird and a bit unconventional. Perhaps itâs because of the time or era when DITA (early 2000s) was defined and the members of the DC imposed their attitudes rather than the actual rules of XML.


I think that itâs important to note that my last two examples are both OASIS standards, so there is precedence for not changing the namespace URI within OASIS.




Sent from Mail for Windows 10


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