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] The Cocoloco Agreement of 2013 on ids for Akoma Ntoso

Dear Fabio,

I don't understand well the sentence  "While it is unique for the currentId attribute, it is not an xml:id (that is: there is at most ONE currentId attribute with that value, but there may be other id attributes with the same value, possibly pointing to different fragments"

I think (but may be I am wrong) that, taking into account the fact that an xml instance can contain multiple akoma ntoso document
(in the case of documentCollection, or attachment, ...) , it is not garantee that the currentId is unique inside the xml instance  (it can exist multiple "art5" in an xml instance)

If this is correct, it is strange to call "id" something that is not an id in the sense of xml.

But maybe it will be more clear when the syntax of this attribute will be normalised.

Kind regards


aubay   Véronique Parisse

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


De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de Fabio Vitali [fabio@cs.unibo.it]
Envoyé : dimanche 15 septembre 2013 17:54
À : <legaldocml@lists.oasis-open.org>; akomantoso-xml@googlegroups.com
Objet : [legaldocml] The Cocoloco Agreement of 2013 on ids for Akoma Ntoso

Dear all,

on Friday 6th 2013, at the end of the dinner for the end of the Summer School on Legislative XML in Ravenna (Italy), four people were forcibly put close together around a table, much to the amusement of the rest of the diners, and denied desserts until they reached an agreement on the formalization of ids in Akoma Ntoso documents. Not wanting to distinguish between torturing and tortured individuals, I will just list here the names of these four people: Monica Palmirani, Veronique Parisse, Grant Vergottini and Fabio Vitali. After much discussion and a little alcohol, @ 22:25 of the same night they succeeded and were able to have their desserts.

Since this happened at the restaurant Bagno Cocoloco in Marina di Ravenna ( http://goo.gl/w3NSnv ), I suggest we release this to history as the "Cocoloco Agreement of 2013". Attached you will find a scan of the signed copy of the agreement, and in the following my very own transcription of the content of the page.


Globally Unique Identifier: global, permanent, long, according to local syntax. Optional.

originalId: local, permanent, short, semantic, forced syntax. Used only when different from currentId. Not required.

currentId: local, non-permanent, short, semantic, forced syntax, required change when renumbering. Non an xml ID. mandatory

functional reference: standardized user identification of the fragment in the AKO document. »


This is my interpretation of the agreement:

<interpretation source="#fv">

There will be exactly three attributes, one of which is required in all documents, and the two others optional.

The only required attribute, familiarly known as currentId, is a standardized functional reference to the fragment, is generated at the creation of the fragment according to a standard, forced syntax and it is short, semantic, and local (that is, different documents may use the same ids for completely different purposes). While it is unique for the currentId attribute, it is not an xml:id (that is: there is at most ONE currentId attribute with that value, but there may be other id attributes with the same value, possibly pointing to different fragments). The currentId value needs to be updated to the new semantically correct value upon renumbering or restructuring of the corresponding fragment (i.e., if fragment clause 5 of section 3 becomes clause 2 of section 12, the currentId gets updated from "sec3-cla5" into "sec12-cla2").

The second attribute, familiarly known as "originalId", is a non-required, permanent reference to the fragment, and it is required whenever the fragment is restructured or renumbered. It inherits the value of the first currentId, and never changes again from then on.

The third attribute, called GUID for Globally Unique Identifier, is a non-required, permanent reference to the fragment. It is fully optional (i.e., the user is free to decide whether to use it or not). It is global across the whole document set, and never changes across versions. No syntax is forced, but since a different value must be generated for every structure of every document of the document set, we expect it to be a rather long string (30 or more characters, for instance).


I hope I was able to capture exactly the nuances of the agreement. I await your comments.

Implementing the way I understood, this agreement requires the addition of an attribute, the renaming of the existing two in originalId and currentId, and some modification in the section  about ids of the release notes.

I am open and in favor of actually naming currentId simply as id.

I am also open to the possibility of calling the other ids as something else, but I kind of like originalId and GUID.

I hope I did not forget anything in this report. Please crucify me gently if I did.




Fabio Vitali                            Tiger got to hunt, bird got to fly,
Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
phone:  +39 051 2094872              Man got to tell himself he understand.
e-mail: fabio@cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's cradle"

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:

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