[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legaldocml] On ids for structures in multipleVersions documents
Dear Fabio,
thank you very much for your email. It is really clear and nice (especially in the part where you list the obvious things :-)), but let me list some doubts coming from my experience with the end-users (and form about 100.000 XML legal documents marked-up with NormeinRete and Akoma Ntoso).
I want to beg pardon to the TC members for this long email and I am also sorry for the English mistakes, but it is a sort of analysis report on the ID. I hope Fabio will find it useful and, as usual, he could find the best solution for the success of Akoma Ntoso.
I have decided to proceed in the analysis with critical questions.
Should ID naming convention be mandatory and normative in LegalDocML specs?
I am convinced that the ID convention should be maintained apart from the XML-schema (that is normative) in our LegalDocML workplan. Considering also that OASIS thinks to open a new TC inside of LegalXML-sc called “Universal Legal Citation”, it is reasonable not to close Akoma Ntoso only to our ID naming convention, but to permit also other ID policies. For this reason also alternative naming conventions could be eligible if they respect the pillars of Akoma Ntoso. Just for example, if instead of “sec9” an institution would like to use “section9” it is not the end of the world.
In my option LegalDocML TC can suggest or recommend something about ID, but not impose strong rules on the syntax, simply because this topic (ID policy) depends often to institutional decisions, internal workflow, integration with other legacy systems, archiving national rules, digital signature processes, complicated and convoluted internal reasons, and so.
An important goal, in my opinion, for our TC is to define some strong pillars concerning the ID for permitting:
1) a robust mechanism for those institutions that start from scratch;
2) good practices for interoperability;
3) a mapping mechanism between existing naming convention and our Akoma Ntoso system.
Should ID be meaningful and unique?
Yes, for sure. These are pillars. For the Art. 8 we have something like “art8” and for section 9 something like “sec9”. For the Section 9A we have “sec9A”. Not something like x4956.
Do we need evolvingID?
Yes, for sure. We need to have two IDs:
- one is the original ID, persistent and not changeable
- one is the new ID according with the naming convention and aligned with the textual changes in the legal document. We could use this ID also for the references (e.g. /us/act/GovernemntCode/main#art11343.4).
Which role has evolvingID?
Following the current version of the release note evolvingId is so defined:
“the id attribute contains the persistent identifier, while the evolvingId attribute contains the identifier that should be used if this fragment was alone, without previous history or similarly named fragments.”
My proposal is to invert the functionalities of the two IDs for the reasons that I am trying to explain later.
“the evolvingId attribute contains the persistent identifier, while id the attribute contains the identifier that should be used if this fragment was alone, without previous history or similarly named fragments.”
And to change the name of evolvingId in persistentID.
Should ID be changeable?
The release note says “NO” and for sure at least one between Id and evolvingId must not change.
My proposal is: to maintain not changeable evolvingId. In case the name should be changed in persistentID and make it mandatory.
Let me list some motivations in support of my thesis.
1) Isomorphism with the text
The text says "art. 8" and you don't know in which version you are when you start to mark-up. You don’t know if in the world (e.g. in some committee, in the same chamber or in another chamber) exists a previous version where "art. 8" previously was "art. 3". You know only that the text says: "art. 8" so the only option that you have is to coordinate the ID attribute with the text. Bill is often in this situation during the legal drafting and we really risk to have a strange ID attribute. Any other information (evolvingID) is about additional legal knowledge and it doesn’t belong to the basic evidence from the text. If the art. 8 was before art. 3 is an extra legal knowledge that needs interpretation and human effort.
2) NLP tools
If we don’t use the isomorphism principle abovementioned, NLP tools could not be useful for extracting in automatic way the ID properly from the text. If the text says "art. 8" the NLP parser can only to produce an id="art8", not "art3". Otherwise we should know other information that could not be in our hands or need more effort (e.g. human, automatic tools, open the old document, etc.. ).
Also in the references we have some problems.
A fragment of text like this that was renumbered and changed several times:
“Section 11343.4 of the Government Code”
is marked up in this way (using NLP tools):
<ref id="ref1" href="" 11343.4 of the Government Code</ref>
Since the URI uses the ID attribute as a fragment part for specifying the internal anchor of the document, we have an evident pointer that we don’t know if it works. Probably due to several modifications of the GovernementCode the original, persistent ID attribute is completely different from the current version. In this case we need a piece of software (resolver and database) to resolve properly the navigation to the correct part of the GovernmentCode.
3) disHarmonization: two IDs, many different uses
In the same document we could have some sections/articles with the evolvingID and some other without it. Some IDs could be coherent with the text and other be not (e.g. id=”art2new”). Simply because in a bill not all the sections/articles are affected by modifications or renumbering actions, we have a very variety of kind of IDs metaphor.
That means that we could have a not harmonized situation like this:
- ID=”art3” that is art3 because it was not affected at all to any modification
- ID=”art3” that is art2 because it was renumbered
- ID=”art2new” that is a new element because it never exists before
- ID=”art2fra” that is the version in France
- ID=”art2v1” that is the new version in multi-versioning document.
What happens if I have a multi-versioning bill in French and I need to renumber the new version in the 20th step of the legislative process?
Id=”art2franewv20” evovlingID=”art3”
I think we need to harmonize a little bit the naming convention in order to make the mark-up easier and usable with automatic tools.
4) Navigability: backward or forward?
If the art. 2 becomes art.3, the XML fragment, following the release notes, it will be the following:
<article id="art1">
<num>1</num>
<content><p>Originally article 1</p></content>
</article>
<article id="art2new" evolvingId="art2">
<num>2</num>
<content><p>New article 2</p></content>
</article>
<article id="art2" evolvingId="art3">
<num>3</num>
<content><p>Originally article 2</p></content>
</article>
<article id="art3" evolvingId="art4">
<num>4</num>
<content><p>Originally article 3</p></content>
</article>
The main problem here is the references (<ref>) among the connected documents to a bill (motion, explanatory summary, motivos).
Take in consideration this reference:
<ref id="ref1" href="" 1</ref>
This reference, when it is transformed in HTML link, should point out to the article 1. The resolver needs to use the ID attribute because article 1 has only this attribute.
Take in consideration this reference:
<ref id="ref2" href="" 3</ref>
This reference, when it is transformed in HTML link, should point out to the art. 4 using the ID attribute or the evolvingID?
It depends to the date of the document in which the link is included and how many renumberings the art. 3 has had.
The resolver of those links is really a difficult task to manage between ID, metadata and evolvingID.
If we have the following fragment of XML:
<article id="art1" persistentID="art1">
<num>1</num>
<content><p>Originally article 1</p></content>
</article>
<article id="art2" persistentID="art2new">
<num>2</num>
<content><p>New article 2</p></content>
</article>
<article id="art3" persistentID="art2" >
<num>3</num>
<content><p>Originally article 2</p></content>
</article>
<article id="art4" persistentID="art3">
<num>4</num>
<content><p>Originally article 3</p></content>
</article>
We could use always the ID and metadata for deciding the correct navigation and the persistentID for any other purpose.
Pros:
We can navigate easily the nodes using an harmonized metaphor and a clear algorithm.
We could use NLP tools for detecting the fragment of the text and use it for the ID. The same for the legal references.
We have in any case a persistent ID.
Finally since the evolvingId is not mandatory, it is possible that we may not have enough information.
For this reason I suggest to make this attribute evolvingId mandatory.
4) Digital signature
Bills, acts and legal documents more and more are managed with digital signature (also in US).
XadES, a new format of digital signature in XML, permits to sign some nodes of an XML document only.
CadES permits to sign all the document.
In EU these kinds of digital signatures are legally valid and used in the majority of Official Gazette or Journal (e.g. Austria, Italy, France, etc.).
If a bill is signed with digital signature and we adopt the multi-versioning, we can’t modify the previous multi-versioning parts.
So the following fragment is not eligible because the “old version of art. 2” was signed in T1 and it is not modifiable.
<art id="art2" evolvingId="art2">
<num>2</num>
<content>
<p>New version of art.2</p>
</content>
</art>
<art id="art2v1" evolvingId="art2">
<num>2</num>
<content>
<p>Old version of art.2</p>
</content>
</art>
For this reason it is eligible the following fragment (using XadES that permits signature on XML nodes) where the persistentID was not modified and the id is incremental:
<art id="art2-v1" persistentID="art2">
<num>2</num>
<content>
<p>New version of art.2</p>
</content>
</art>
<art id="art2" presistentID="art2">
<num>2</num>
<content>
<p>Old version of art.2</p>
</content>
</art>
This is reasonable also for maintaining navigable the links from the old documents, already signed and fixed, without any further changes.
Moreover if we have an internal reference to art.2 to the first version fixed in the t1, we have this fragment of XML:
<ref id="ref2" href="" 2</ref>
we need to change also all the internal references to the multi-versioning fragments in this:
<ref id="ref2" href="" 2</ref>
5) Additional issue for the ID
The components inside of the <documentCollection> need to be regulated as well with some rules.
If I have three different versions of the same bill included in the same <documentCollection> (it is possible, those bills come from three different parties/committees in the meantime and presented to the parliament) I will have some problems to manage the conflicting ID.
The same bill in three different variants needs some extra rules not included in the release notes yet .
Another similar scenario is to have three different bills (three different works) included in the same <documentCollection> with conflicting IDs.
Recap of my proposals (listed by priority and in alternative):
1) evolvingID changes role and it is a persistence ID (never change) and the navigation is based always on ID attribute (no modifications in the XSD but in the release notes).
2) evolvingID is mandatory. All the navigation is based always on evolvingID. Also the internal references use it (little impact on current release).
3) to permit both role of evolvingID: presistence ID or changeable ID (not a nice solution but backward compatible).
What do you think? I hope your good answers will be more than my doubts.
Have a good holiday,
Monica
Il 10/08/2013 10:02, Fabio Vitali ha scritto:
Dear Grant, Monica,
The confusion over the evolvingId or temporalId has left me wondering whether a single Id attribute would not be better as a GUIDy thing without any hint of the number
I had this very discussion less than 12 months ago with technical people from the European Commission (not the Parliament, the Commission).
It seems as if there is something in the brain of computer scientists that make them believe that the only job of an id is to be unique within the document, and for this reason it can be any absurd string of characters as long as it isn't repeated anywhere else. Of course, for computer scientists, unique ids are stable across versions, so it is safe to assert that whatever was identified by some id in the initial version will be identified by the same id in all subsequent versions.
Next thing it happens is that you talk to legal experts and tell them: "so there is the id for, say, section 9, let's say the value of the id is actually 'xy45a3', and you place it after the "#" character of the URI and voilà you have your link". And they will ask you: "Ok, this is cool, but now how do I know the id of the next section, that is to say, section 10?" And you will say: "You can't know it beforehand: you have to look it up in the source and check whatever absurd string of character has been chosen for section 10." and they will stare blankly at you as if this was the pun of a joke that they did not get, and ask simply, in a very low voice: "Why?"
And not only legal experts: archivists have the same point of view, and librarians, and publishers, and medical students, etc. They all understand that the id, to be useful, has to be meaningful in some other manner than simply being unique: it has to carry within itself at least SOME information about the thing it identifies. For them, this is not subject to argumentation: it is an evident truth that is pointless to discuss, like the sun is not green, Justin Bieber is not male, Ferraris are red and Brazilian soccer teams do not play the chain ( http://en.wikipedia.org/wiki/Catenaccio ).
On this very topic, I would like to point you again to section 7.4 of the Release Notes, and in particular to the list starting with "Our solution must maintain some fundamental principles: ", and in particular with item 8, "Meaningfulness: the id of a part must, as much as possible, express basic facts about its nature, position, or relation to superior and/or neighboring elements that are meaningful to the local tradition.".
This is a fact so ingrained in the mind of jurists that sometimes they consider all too natural to go to the exact opposite... For instance, I had exactly the opposite discussion with Monica not later than last week, again about ids in bills. She was asserting that since renumbering in bills is a frequent operation, and in enacted laws it is rather rare, it makes sense to allow two different policies for ids, whereby in acts you maintain the same id across versions, and use evolving ids for the id the structure would have now, while in bills you do exactly the opposite, and update the ids to whatever is the structure number after the renumbering, and use evolvingIds to record the original id. This would violate basically every item of the above mentioned list, plus item 0 that we never cared to express, namely "Homogeneity: there must be ONE solution and it needs to be applied in the same way to all document types and parts".
So let me come back to the discussion, again as expressed in section 7.4: there are two opposite needs for identification, one that needs to be persistent, so as to allow easy tracking of the same entities across versions, and another that needs to be meaningful, so as to be able to associate easily the id to its entity and the entity to its id, without the need of global lookups within the document. These opposite needs completely overlaps when no renumbering happens, and dramatically contrast every time a renumbering happens.
The solution adopted so far has been to have two separate sets of identifiers, one of which is persistent and the other is meaningful. Which of them is called id and which is called something else is irrelevant, but it seems to me that any solution that sets either persistency or meaningfulness as the only relevant requirement throwing away the other is inherently wrong, and any solution that requires different approaches for different types of documents is even worse.
So the way I see it is that both you and Monica hate evolvingId with the purest of your heart, but from completely different points of view, and that the usefulness of evolvingId can only be denied by denying the very need of a compromise between persistency and meaningfulness, which you both do but from opposite positions.
I hope I was convincing...
Ciao
Fabio
--
Il giorno 25/lug/2013, alle ore 08:09, Grant Vergottini <grant.vergottini@xcential.com> ha scritto:
Hi Fabio,
I finally got some quality time to sit down and look over this. I understand the two approaches - and depending on the scope of the change, one is better than the other as you note.
I do worry that the Id management is going to be very difficult in an application. This whole issue has come up for me in the past week on work we're doing for the US House. It seems to me that maintaining the original section number in the Id across time will only lead to confusion in the minds of the developers that will work with the data. I've tried to explain the notion of the evolvingId vs. the id on several occasions now only to get confusion back. Another approach I have tried is to describe the Id as time independent Id and the evolvingId as a time dependent Id - actually calling it a temporalId instead and explaining it as an Id that only can exist at a point-in-time - as it's dependent on a specific state. That approach has been better understood, but in the end is controversial too.
The confusion over the evolvingId or temporalId has left me wondering if it makes sense to have it at all, and whether a single Id attribute would not be better as a GUIDy thing without any hint of the number. This is similar to how the US House already assigns identifiers and how Hong Kong appears to assign identifiers. Actually, if I'm seeing it right, the existing Hong Kong system assigned two concatenated GUIDs to create the Id. The first half stays the same across all versions while the second half gets reassigned a GUID value from version to version. The end result is the same - a long jumble of alphanumeric characters.
What purpose does the evolvingId attribute serve? Why is it necessary? I know I've been one who has elevated the role of the evolvingId attribute, but I'm wondering if there perhaps isn't a better way to sidestep the confusion that results when an id attribute tries to have a meaningful value based on something that varies with time - like the "num".
-Grant
On Tue, Jul 23, 2013 at 12:52 PM, Fabio Vitali <fabio@cs.unibo.it> wrote:
Ciao.
I had a remaining task I promised last week to Grant, i.e. to provide my own point of view on how to solve the riddle of managing multiple coexisting versions of the same structure (say, section 9 of a bill) in a multi-versioning document (i.e., a document that maintains data about multiple subsequent versions and can be used to display the content of any of them).
Let's make a simple example. Here you have section 9 of a bill as presented on January 1st, 2013. Each month (to simplify) it gets renumbered, first to 7 and next to 13 and finally again to 9, but the content never changes. The version of January 1st is a originalVersion, all the subsequent ones are multipleVersions.
FIRST VERSION
-------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="originalVersion" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval refersTo="#firstVersion" start="#e1" />
</temporalGroup>
</temporalData>
<references source="#fv"> ... </references>
</meta>
<body>
...
<section id="sec9">
<num>Section 9</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
Pretty simple so far. On February 1st, a new version of the document gets approved, where section 9 is now section 7 and nothing else. The manifestation of the new _expression_ becomes multipleVersions, we now have three temporalInfo elements (what has remained without changes, what has been deleted in version 2 and what has been inserted in version 2).
As for the body, we have two choices. The first one is to mark simply and exactly the text fragments that have changed. Therefore there is still only ONE section element, and id and evolving ids are used as needed and we have two spans in the CONTENT of the num element associated to one or the other of the temporalInfo elements, as follows:
SECOND VERSION, APPROACH ONE
----------------------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="multipleVersions" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
<eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval id="ti1" refersTo="#originalVersion" start="#e1" />
<timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" />
<timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" />
</temporalGroup>
</temporalData>
<references source="#fv"> ... </references>
</meta>
<body>
<section id="sec9" evolvingId="sec7">
<num>Section
<span id="sp1" period="ti2">9</span>
<span id="sp2" period="ti3">7</span>
</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
The second approach is to duplicate the section element, and to maintain identity as follows: the currently existing section with the new content maintains the id, plus the evolving id, while the old section, maintaining the old content, has some appropriate identifier and no evolvingId (because it does not exist now and therefore needs no evolvingId). Furthermore, we add a renumberingInfo element to keep track of the changes (when only dealing with two versions, this element does not provide any additional information than evolving ids, but is will change from the second renumbering.
SECOND VERSION, APPROACH TWO
----------------------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="multipleVersions" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
<eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval id="ti1" refersTo="#originalVersion" start="#e1" />
<timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" />
<timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" />
</temporalGroup>
<renumberingInfo id="rI1" originalId="#sec9" evolvedId="sec7" start="#e2"/>
</temporalData>
<references source="#fv">... </references>
</meta>
<body>
<section id="sec9-1" period="#ti2">
<num>Section 9</num>
<heading id="sec9-1-h">Some heading</heading>
<content id="sec9-1-cnt">
<p>Some content</p>
</content>
</section>
<section id="sec9" evolvingId="sec7" period="#ti3">
<num>Section 7</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
Ok so far? The choice between approach one and approach two is left to the marker, and in my mind it clearly depends on how much of section 9 has been changed besides the simple number. If much has changed, then approach two is better, if only the number has changed, then approach one is better.
-----
On March 1st, the section gets renumbered again, this time to 13. Now we know the drill and the two approaches still work. Please note that in the two approaches the section meta is identical, while the body is different.
THIRD VERSION, APPROACH ONE
----------------------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="multipleVersions" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
<eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" />
<eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval id="ti1" refersTo="#originalVersion" start="#e1" />
<timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" />
<timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" />
<timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" />
<timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" />
</temporalGroup>
<renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/>
<renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3"/>
</temporalData>
<references source="#fv"> ... </references>
</meta>
<body>
<section id="sec9" evolvingId="sec7">
<num>Section
<span id="sp1" period="ti2">9</span>
<span id="sp2" period="ti4">7</span>
<span id="sp3" period="ti5">13</span>
</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
THIRD VERSION, APPROACH TWO
----------------------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="multipleVersions" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
<eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" />
<eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval id="ti1" refersTo="#originalVersion" start="#e1" />
<timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" />
<timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" />
<timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" />
<timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" />
</temporalGroup>
<renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/>
<renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3"/>
</temporalData>
<references source="#fv"> ... </references>
</meta>
<body>
<section id="sec9-1" period="#ti2">
<num>Section 9</num>
<heading id="sec9-1-h">Some heading</heading>
<content id="sec9-1-cnt">
<p>Some content</p>
</content>
</section>
<section id="sec9-2" period="#ti4">
<num>Section 7</num>
<heading id="sec9-2-h">Some heading</heading>
<content id="sec9-2-cnt">
<p>Some content</p>
</content>
</section>
<section id="sec9" evolvingId="sec13" period="#ti5">
<num>Section 13</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
Finally, on April 1st, we renumber the section back to section 9, but we want to maintain the twists that the section has gone through in the past.
FOURTH VERSION, APPROACH ONE
----------------------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="multipleVersions" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
<eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" />
<eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" />
<eventRef id="e4" date="2013-04-01" source="#pr3" type="amendment" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval id="ti1" refersTo="#originalVersion" start="#e1" />
<timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" />
<timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" />
<timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" />
<timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" />
<timeInterval id="ti6" refersTo="#repealedinVersion4" start="#e3" end="#e4" />
<timeInterval id="ti7" refersTo="#addedinVersion4" start="#e4" />
</temporalGroup>
<renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/>
<renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3" end="#e4"/>
<renumberingInfo id="ri3" originalId="#sec9" evolvedId="sec9" start="#e4"/>
</temporalData>
<references source="#fv"> ... </references>
</meta>
<body>
<section id="sec9" evolvingId="sec7">
<num>Section
<span id="sp1" period="ti2">9</span>
<span id="sp2" period="ti4">7</span>
<span id="sp3" period="ti6">13</span>
<span id="sp4" period="ti7">9</span>
</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
FOURTH VERSION, APPROACH TWO
----------------------------
<akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05">
<bill contains="multipleVersions" name="bill">
<meta>
<identification source="#fv"> ... </identification>
<lifecycle source="#fv">
<eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" />
<eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" />
<eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" />
<eventRef id="e4" date="2013-04-01" source="#pr3" type="amendment" />
</lifecycle>
<temporalData source="#fv">
<temporalGroup id="tg1">
<timeInterval id="ti1" refersTo="#originalVersion" start="#e1" />
<timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" />
<timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" />
<timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" />
<timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" />
<timeInterval id="ti6" refersTo="#repealedinVersion4" start="#e3" end="#e4" />
<timeInterval id="ti7" refersTo="#addedinVersion4" start="#e4" />
</temporalGroup>
<renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/>
<renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3" end="#e4"/>
<renumberingInfo id="ri3" originalId="#sec9" evolvedId="sec9" start="#e4"/>
</temporalData>
<references source="#fv"> ... </references>
</meta>
<body>
<section id="sec9-1" period="#ti2">
<num>Section 9</num>
<heading id="sec9-1-h">Some heading</heading>
<content id="sec9-1-cnt">
<p>Some content</p>
</content>
</section>
<section id="sec9-2" period="#ti4">
<num>Section 7</num>
<heading id="sec9-2-h">Some heading</heading>
<content id="sec9-2-cnt">
<p>Some content</p>
</content>
</section>
<section id="sec9-3" period="#ti6">
<num>Section 13</num>
<heading id="sec9-3-h">Some heading</heading>
<content id="sec9-3-cnt">
<p>Some content</p>
</content>
</section>
<section id="sec9" evolvingId="sec9" period="#ti7">
<num>Section 9</num>
<heading id="sec9-h">Some heading</heading>
<content id="sec9-cnt">
<p>Some content</p>
</content>
</section>
</body>
</bill>
</akomaNtoso>
That is all. I hope I did not make errors in the markup. I also hope I was clear and exhaustive. I surely was exhausting, but alas, what could I do?
Ciao
Fabio
--
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"
http://vitali.web.cs.unibo.it/
---------------------------------------------------------------------
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
--
____________________________________________________________________
Grant Vergottini
Xcential Group, LLC.
email: grant.vergottini@xcential.com
phone: 858.361.6738
--
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"
http://vitali.web.cs.unibo.it/
---------------------------------------------------------------------
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
====================================
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]