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: RE: [legaldocml] Making my case for keeping the AKN namespace URI as is --- forever.


Dear Monica,

I am sorry, but I will not be available the whole next week.  So, the 3 october is not possible for me.

Regarding the solution you propose, I find an issue in the fact that no versioning information will be done as in this solution, we cannot add the attribute for the version without changing the namespace (as Fabio indicates, this attribute is a no-backward compatible change), except if we accept that the attribute for the version is optional.

Kind regards

Véronique



Véronique Parisse

AUBAY Luxembourg

Orco House
38, Parc d’activités - L-8308 Capellen
Standard : +352 2992501
Fax : +352 299251

www.aubay.com




De : legaldocml@lists.oasis-open.org <legaldocml@lists.oasis-open.org> de la part de monica.palmirani <monica.palmirani@unibo.it>
Envoyé : mercredi 26 septembre 2018 22:22
À : legaldocml@lists.oasis-open.org
Objet : Re: [legaldocml] Making my case for keeping the AKN namespace URI as is --- forever.
 
Dear all,

I have investigated the namespace issue with the OASIS Staff and we can say that after the fragment.../legaldocml/ns/... in the URL, the namespace text is under the TCs control.

However the important issue is to not affect the interoperability and the transparency.
For this reason OASIS Staff suggests this policy. To add in the documentation and also in the next XSD the following sentence:

 "It is the intent of the OASIS LegalDocumentML (LegalDocML) TC that XML namespace names identified by URI references 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 Specification Draft, results in non-backwardly compatible changes from a previously published Committee Specification Draft."

I recommend to attend the next LegalDocML TC in order to discuss the Grant's request, the Fabio's suggestions and to deliberate a possible solution.
We propose the next TC meeting at October 3rd 6.30PM. I hope it is ok for most of you.

Please find in attachment the preliminary list of the modifications for the next AKN release.

Best regards,
Monica


Il 21/09/2018 00:43, Fabio Vitali ha scritto:
Dear Grant,

I have read and thought a lot about your mail. Although I am not completely convinced about your reasons, I definitely believe there is merit in them. Also, I understand that you feel strongly about it, so I am willing to consider the idea of freezing the namespace once and forever. 

I have a few requests for the group, though, before I commit to this decision: 

1) This is the LAST TIME we decide on this issue. If we decide to freeze the namespace, we FREEZE THE NAMESPACE  for good, and we will never ever ever ever ever again change our mind or even try to suggest we might possibly give a shot to evaluate whether we could eventually end up reconsidering this decision. This is the deal breaker for me. 

Also, I do not believe for a moment that we will approve only backward compatible modifications to the language from now on. Such compatibility will be a happy and welcome characteristic of most modifications we will discuss and approve, but TIME WILL COME when someone proposes an incompatible modification and people in the group will go "well, this time only, it is minor, it is very important in this context, most users will never even notice it", and bang, we have approved it. THEREFORE: 

2) We impose the specification of the version of the vocabulary in an attribute in the <akomaNtoso> root element. This attribute becomes a required attribute from now on, and it allows a FIXED SET OF VALUES for all backwards-compatible versions of the language. The attribute actually becomes required for all versions AFTER 3.0, i.e., it *cannot* be placed into 3.0 documents, and it is *required* for all documents of later versions (this is by itself a non-backward-compatible modification). Trying to validate a document without such attribute or with the attribute having a weird value will return a validation error right at the beginning of the validation phase. 

3) I don't like the "version" attribute, which would seem to have *the Akoma Ntoso language* as the subject of the RDF statement to be generated by its specification. I nonetheless am willing to consider an attribute that implies *this specific manifestation* as the subject of the RDF triple. I suggest "uses", as follows: 

<akomaNtoso uses="akn31" 
           xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://docs.oasis-open.org/legaldocml/ns/akn/3.0 ./akomantoso31.xsd">
The attribute "uses" would allow a fairly straightforward representation in RDF as follows: 

<manifestationURI> akn:uses <akomantoso31URI>.
which I would be fine with. I have no firm opinion about the actual syntax of the values of the 'uses' attribute. 

4) "backward compatibility" is defined to mean "compatibility of all possible documents", and not, weakly, "compatibility of all the documents that exist". Thus, by construction, version X+1 of Akoma Ntoso is backward compatible with version X of Akoma Ntoso    IFF     *every possible document that is valid with version X is also valid with version X+1*. Therefore we MUST know in advance which modifications to the language would create a backward incompatibility, and act accordingly in the language. 

Suppose for instance that version 3.4 is backward compatible with 3.3, 3.2 and 3.1 (it cannot possibly be compatible with 3.0, of course). If, on the approval of version 3.5, we notice that this creates a non-backward compatible version, then 

<xsd:simpleType name="akomaCompatibleVersionType">
	<xsd:restriction base="xsd:string">
		<xsd:enumeration value="akn31"/>
		<xsd:enumeration value="akn32"/>
		<xsd:enumeration value="akn33"/>
		<xsd:enumeration value="akn34"/>
	</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="akomaNtosoType">
 <xsd:sequence>
   <xsd:group ref="documentType"/>
   <xsd:element ref="components" minOccurs="0" maxOccurs="1"/>
 </xsd:sequence>
 <xsd:attribute name="uses" type="akomaCompatibleVersionType"/>
</xsd:complexType>

<xsd:element name="akomaNtoso" type="akomaNtosoType"/>

would be in the xsd of version 3.4, while

<xsd:simpleType name="akomaCompatibleVersionType">
	<xsd:restriction base="xsd:string">
		<xsd:enumeration value="akn35"/>
	</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="akomaNtosoType">
 <xsd:sequence>
   <xsd:group ref="documentType"/>
   <xsd:element ref="components" minOccurs="0" maxOccurs="1"/>
 </xsd:sequence>
 <xsd:attribute name="uses" type="akomaCompatibleVersionType"/>
</xsd:complexType>

<xsd:element name="akomaNtoso" type="akomaNtosoType"/>

would be in the xsd of version 3.5.

If we agree with ALL of this, I can be convinced to accept the idea.

Ciao

Fabio

--


Il giorno 19 set 2018, alle ore 22:21, Grant Vergottini <grant.vergottini@gmail.com> ha scritto:

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.

-Grant

Sent from Mail for Windows 10
--

Fabio Vitali                                          The sage and the fool
Dept. of Informatics                                     go to their graves
Univ. of Bologna  ITALY                               alike in this respect:
phone:  +39 051 2094872                  both believe the sage to be a fool.
e-mail: fabio@cs.unibo.it                  Where, then, may wisdom be found?
http://vitali.web.cs.unibo.it/   Qi, "Neither Yes nor No", The codeless code




--

Fabio Vitali                                          The sage and the fool
Dept. of Informatics                                     go to their graves
Univ. of Bologna  ITALY                               alike in this respect:
phone:  +39 051 2094872                  both believe the sage to be a fool.
e-mail: fabio@cs.unibo.it                  Where, then, may wisdom be found?
http://vitali.web.cs.unibo.it/   Qi, "Neither Yes nor No", The codeless code


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

.


-- 
===================================
Associate professor of Legal Informatics 
School of Law
Alma Mater Studiorum Università di Bologna 
C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/ 
Palazzo Dal Monte Gaudenzi - Via Galliera, 3 
I - 40121 BOLOGNA (ITALY) 
Tel +39 051 277217 
Fax +39 051 260782 
E-mail  monica.palmirani@unibo.it 
====================================



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