RE:RE:[legaldocml] Issue with components I am not sure how to model (NOW

Dear Fabio,

As you said, today we have two technics to store, in one file, the content of a document and of all its components

Put each document inline, where it is called, so each content of the component is placed where it is used (hierarchical representation : if the component is composed of sub-documents, the same technic can be applied).
Put all the included documents at the end of the XML file inside the "components" element and make a reference to them from their effective location (documentRef, componentRef). There are no more hierarchical storage of the "components" of a document : they are all grouped at the end of the file without taking into account their effective location.

The request is to add a new grouping for the included documents, allowing each document to have its own "components" element ; so, there will be two methods for storing, hierarchically in a file, a document and all its components : inline or inside a "components" element at the end of the document.

Based on this request, an additional request is to remove the "components" element as sub-element of akomaNtoso element.

Of course, I agree with the first request, to allow the "components" element inside a document element, as an alternative technic to the inline technic.

Now, the question is : is the "components" at the end of the file already necessary or can we remove it ?

If we remove the "components" at the end of the file, then it means that the implementation of the flatting solution (all components collected in a single position, without hierarchy) is done by simulating it using the "components" element of the overall including document (first level document).

Doing it, the content of the components of the first level document is ambiguous : it can contain all the components using the flat technic or only the components directly referenced by it (hierarchical technic).

Leaving the "components" element at the level of the file and allowing it also inside the document make clearer the usage of the "components" and business rules can be based on it (avoid the "components" inside a document if "components" is defined at the level of the file in the same document, ...).

So, in conclusion my preference it to add the components element inside each "document" element and remain it also as sub-element of akomaNtoso element.

At last remark, I think that the complexity of the id computation is very similar whether "components" element is at the end of the file or at the end of the document.

But this is a more general problem : each time a file includes the content of multiple documents (multiple content), the id is to redefine also for elements (article, paragraph, ...) except if exists a strategy to define an "universal id" for each element so that the id can remain immutable.

Kind regards

Véronique Parisse

De : Fabio Vitali [fabio@cs.unibo.it]
Envoyé : lundi 20 mai 2013 14:50
À : PARISSE, Véronique
Cc : Grant Vergottini; legaldocml@lists.oasis-open.org
Objet : RE:[legaldocml] Issue with components I am not sure how to model (NOW WITH COLORS!)

Dear all,

let me come back to this discussion, in order to reach some consensus for a rapid vote and a rapider version of the schema. Let me summarize the discussion as I see it:

1) Akoma Ntoso recognizes the existence of complex documents, whose individual components may have their own identity and nature. There are basically two types of complex documents, both handled more or less in the same way: individual documents with (a complex maze of) attachments or document collections composed of a number of individual documents (and their attachments).

2) In both cases, Akoma Ntoso gives the author of the markup the possibility of placing the individual components in three different ways:

* inline, in the position where they should naturally reside, if no externalization were possible

* in a separate XML file/document/flow, referred to via a componentRef or documentRef

* in the same XML file/document/flow, but in a separate position acting as a clearing house of the pieces that may make the structure of the complex document less evident, referred to via a componentRef or documentRef

3) Whatever solution is chosen, it is a Manifestation-level decision, with no impact on the content levels such as Expressions and Work: regardless of their physical position at the Manifestation level, their conceptual position at the _expression_ level and Work level is always inline, in the exact position where they should naturally reside. So from the legal point of view, and from the semantic point of view, there is really NO difference at all whatever choice is made, it is only a purely technical matter.

4) The connection between a componentRef or documentRef and the component it refers to is carried out through the URI and/or fragment ID of the component, and thus the component's actual position is completely irrelevant and can be chosen with an extremely open attitude.

Thus said:

5) Currently Akoma Ntoso proposed a single clearing house for internal but not inline components in the <components> element placed after the document type, at the end of the <akomaNtoso> structure, e.g.:

<akomaNtoso>

<documentCollection>

<meta> ...</meta>

<collectionBody>

<documentRef href="">#comp1"/>

<interstitial>Some irrelevant content</interstitial>

<documentRef href="">#comp2"/>
</collectionBody> [example 1]

</documentCollection>

<components>

<component id="comp1">

<bill> ... </bill>

</component>

<component id="comp2">

<doc> ... </doc>

</component>

</components>

</akomaNtoso>

The denounced drawback of this structure is that if one or more components are themselves complex documents with components, they need to be exploded, so that all individual components end up in the same clearing house. Also, all ids need to be verified in order to create no clash.

E.g., if we need to place the following bill

<akomaNtoso>

<bill>

<meta> ... </meta>

<body>...</body>

<attachments>

<componentRef href="">

</attachments> [example 2]

</bill>

<components>

<component id="comp1">

<doc> ... </doc>

</component>

</components>

</akomaNtoso>

in the document collection above, currently we need to de-structure the components and update the ids, as follows:

<akomaNtoso>

<documentCollection>

<meta> ...</meta>

<collectionBody>

 <documentRef href="">#comp1"/>

<interstitial>Some irrelevant content</interstitial>

 <documentRef href="">#comp2"/>
</collectionBody>

</documentCollection>

<components>

<component id="comp1">

<bill> ... </bill>

</component>

<component id="comp2"> [example 3]

<doc> ... </doc>

</component>

<component id="comp3">

<bill>

<meta> ... </meta>

<body>...</body>

<attachments>

<componentRef href="">#comp4"/

</attachments>

</bill>

</component>

<component id="comp4">

<doc> ... </doc>

</component>

</components>

</akomaNtoso>

Many think this de-structuration is overly complex and have proposed a different approach, where the components can be placed near the document block they refer to, as follows:

<akomaNtoso>

<documentCollection>

<meta> ...</meta>

<collectionBody>

 <documentRef href="">#comp1"/>

<interstitial>Some irrelevant content</interstitial>

 <documentRef href="">#comp2"/>
</collectionBody>

<components>

<component id="comp1">

<bill> ... </bill>

</component>

<component id="comp2">

<doc> ... </doc>

</component>

<component id="comp3"> [example 4]

<bill>

<meta> ... </meta>

<body>...</body>

<attachments>

<componentRef href="">comp3-comp1"/

</attachments>

<components>

<component id="comp3-comp1">

<doc> ... </doc>

</component>

</components>

</bill>

</component>

</components>

</documentCollection>

</akomaNtoso>

This approach has the advantage that the new components can be added to the documentCollection directly, with no structural modifications and with completely automatic updates of the identifiers.

I believe that this is a sound proposal and worth the cost of the modification. Let me also point out that even after this modification, it would still be possible to have all components collected in a single position, if you so desire, because the documentCollection itself has its own <components> element (although it is now within documentCollection and not after it), so that, if you like the structure of [example 3], a very similar structure can be generated as follows:

<akomaNtoso>

<documentCollection>

<meta> ...</meta>

<collectionBody>

 <documentRef href="">#comp1"/>

<interstitial>Some irrelevant content</interstitial>

 <documentRef href="">#comp2"/>
</collectionBody>

 <components>

<component id="comp1">

<bill> ... </bill>

</component>

<component id="comp2"> [example 5]

<doc> ... </doc>

</component>

<component id="comp3">

<bill>

<meta> ... </meta>

<body>...</body>

<attachments>

<componentRef href="">#comp4"/

</attachments>

</bill>

</component>

<component id="comp4">

<doc> ... </doc>

</component>

</components>

</documentCollection>

</akomaNtoso>

where the only difference is in ... </documentCollection> <components> ... </components></akomaNtoso>

becoming ... <components> ... </components></documentCollection></akomaNtoso>

Thus a syntax that allows both requirements to be taken care of is in my book preferable to a syntax that only caters for one requirement and not the other.

I propose we approve this modification

Regards

Fabio Vitali

--

Il giorno 08/mag/2013, alle ore 09.49, PARISSE, Véronique ha scritto:

Hello Grant,

Structurally speaking, can we consider this case as similar to the attachment in the context of the European institutions :

“Agreements, protocols, declarations and conventions may be preceded by an act of secondary legislation, which generally approves them. They are ‘attached’ (and not ‘annexed’) to this act (decision or regulation).”

The real new act as the version published independently (as part of the US code (or Title)). It is a new Work, with its own identifier.
The statute would be also the new Work but it cannot be modified by amendments.

The version of new act that is annexed to the approved statute is an historical version and the reflect of an historical decision.
So, personnally, I vould mark it as a component that reference the first _expression_ of the new act (part of US code or Title).

What do you think ?

Kind regards

Véronique

De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de Grant Vergottini [grant.vergottini@xcential.com]
Envoyé : mardi 7 mai 2013 21:17
À : legaldocml@lists.oasis-open.org
Objet : [legaldocml] Issue with components I am not sure how to model

Hi Everyone,

I want to understand how best to model a situation that arises all the time for me - both in California and at the Federal level:

I have a Bill that exists to "enact" a new law.- That new law, should it be approved, will exists as it's own autonomous "Act" that appears to be independent of the Statute that enacted it. In California we have many such Acts generally relating to water rights and Indian gaming. At the Federal level, the classic example is the Bill the creates a new positive law Title. When that Bill is approved, it becomes a Statute and is added to the Statutes at Large. But it also spawns a new document which is the new Title.

So here is what I am wondering. When the Title is drafted and is introduced as a Bill, the proposed Title is enclosed within the Bill and does not have an identity separate from the Bill itself. The proposed Title cannot be amended in any context other than as part of the Bill containing it. But once the Bill is enacted, there will now be two "copies" of the Act or the Title (I'm not sure of the legal rules here). First there is the copy that is an integral part of the Statute (which is also an Act) that results. Second, there is the new Act or the new Title that is part of the US Code. From what I can tell, amendments to the US Code are not also applied back to the originating Statute that created the Title in the first place - so the originating Statute forever more reflects the initial state of the Title.

First of all, is my understanding of this correct? (Tom Bruce, can you shed any light on this?) I have wondered about the legal rules even in California, but never got a definitive answer.

Secondly, how should this be modeled in Akoma Ntoso? Should the part that will become the new Title be modeled as a component? When the Bill becomes a Statute, does it essentially also give birth to a new document that is the Title? Should the Statute make a component reference to the new Title or forever hold an archive of the Title in its original state?

-- Grant
____________________________________________________________________
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/

legaldocml message