OASIS LegalDocumentML (LegalDocML) TC

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  

Hi Grant, thanks for this exhaustive explanation of the issue. As I mentioned in the yesterday chat, we (co-chairs) have already open a question to the OASIS Technical Staff in order to collect enough information if there are some mandatory rules to follow concerning the namespace of new version of XSD standard. This will help to take an appropriate decision on the point and also to simplify the process for the future steps. I am confident that we will find a good solution like for the booklet. Yours, Monica Il 19/09/2018 22:21, Grant Vergottini 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  -- =================================== 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 ====================================

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

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 ==================================== Attachment: LegalDocML-modifications-2018-09-26.xls Description: MS-Excel spreadsheet

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 ====================================