[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#comp1"/> <interstitial><p>Some irrelevant content</p></interstitial> <documentRef href=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#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=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#comp1"/> <interstitial><p>Some irrelevant content</p></interstitial> <documentRef href=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#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=""Apple-style-span" color="#ff0000">#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=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#comp1"/> <interstitial><p>Some irrelevant content</p></interstitial> <documentRef href=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#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=""Apple-style-span" color="#ff0000">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=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#comp1"/> <interstitial><p>Some irrelevant content</p></interstitial> <documentRef href=""Apple-style-span" style="font-family: Monaco; font-size: x-small; ">#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=""Apple-style-span" color="#ff0000">#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, -- 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/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]