Subject: RE:[legaldocml] On ids for structures in multipleVersions documents
Dear Monica, Fabio and Grant
Here is my small stone to the subject.
First, the users want a standardised way for referencing of a block of text (a business reference without the typographic irrelevant information).
This business reference is based on the type of the block structure and on its number (<num> element), sometimes with a hierarchical context.
So, the value of this field will evolve when the structure is renumbered or when his type change (a paragraph becomes a list of points).
But what is a "standardised way" ?
We need to define when the reference must be expressed as a hierarchical reference or not (in an act at EP, the article number can be enough, without mention of his chapter, for example, but I am not sure that it is always the case).
Another question is whether this reference will be alinguistice or not ("article 1a" in one language is "article 1 bis" in another one; sometimes, an "article" in french is a "rule" in english, sometimes, not)
Secondly, we need an unique identifier of the block of text.
This must be persistent as we want to follow the same piece of text through the Expressions. It is also nice if the identifier will be managed to be identical between linguistic version.
Because we need the persistence of the id value, it becomes very complicated if we build this value on a semantic information that is not permanent. It will be more disturbing than helping : when the value at the basis of the id evolves,
the meaning of the id is erroneous.
For applications that manage bills, this type of change is frequent, the renumbering is implicit and furthermore, the old version has no more interest except for historical reason.
The id build on semantic meaning is also difficult to manage with complex documents like documentCollection or document with attachments when we want to group all the documents in one xml instance (the id must be unique for the xml instance
so we need algorithms to garantee this).
After discussion, we arrive, at the European Parliament, at the same conclusion as Grant (and the Commission) : the id is a meaningless value (a sequential number). (Finally, it is like a "number of national register" that identify
We understand the need for standardised referencing of piece of text, but before implementing it, we need to define it clearly. And the value of the reference does not need to be unique inside the xml instance : if a bill has as attachment another bill, it is normal that we have in the xml instance two "article 1". When referencing, the user need to specify if he search inside the attachment or the main bill.
De : email@example.com [firstname.lastname@example.org] de la part de Grant Vergottini [email@example.com]
Envoyé : mardi 20 août 2013 7:02
À : Monica Palmirani
Cc : firstname.lastname@example.org; Fabio Vitali [email@example.com]
Objet : Re: [legaldocml] On ids for structures in multipleVersions documents
Dear Monica and Fabio,
There is a very important consideration when if comes to the @id attribute - how easily Akoma Ntoso can coexist with the infrastructure that is already in place. For this reason, I think that the @id attribute recommendations cannot be normative.
I think that it is highly unlikely that Akoma Ntoso will be deployed into a new environment that has been built from the ground up. More likely, Akoma Ntoso will need to coexist with existing systems - and initially in a support role rather than in a primary role until confidence in the Akoma Ntoso model grows. I'm guessing that initially Akoma Ntoso will be made available through a transform as an output rather than being the internal model.. I am already finding that customers are reluctant to adopt something unproven that is not designed precisely to their spec. But they are willing to adopt it as a transform where the risk is less. In that case, the @id conventions are already in place in the internal model and cannot be modified for the convenience of Akoma Ntoso.
And even if the jurisdiction is willing to adopt Akoma Ntoso more extensively, they probably already have a system with assigned ids in place and it would be preferable, in order to preserve compatibility with existing infrastructure, to preserve those ids.
In California, Hong Kong, and in the U.S. House, the @id attribute is already well established. In all three cases, ids are defined as long meaningless GUIDs. In all three cases, this convention goes back a decade or more (2003 in California, 2000 in the U.S. House, and 1997 in Hong Kong). All three jurisdictions came to the same conclusion independently without any interaction or relationship at all - so I'm quite willing to guess that the three jurisdictions I am dealing will aren't the only ones.
In all three jurisdictions, as we move forward, we are preserving the existing id attribute values to ensure that systems we aren't modifying, which have dependencies on the @id attribute, won't break. It is very important that we allow this in order to allow Akoma Ntoso to be adopted with too much upheaval.
On Tue, Aug 13, 2013 at 12:01 PM, Monica Palmirani <firstname.lastname@example.org> wrote:
Xcential Group, LLC.