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: changes in the documentation (specifications)


Dear Monica and Fabio and all,

During a small mission at the Parliament to analyse the migration of the the parliament's documents from the version 2 of Akoma Ntoso to the version 3, I find some texts that needs to be changed, I think, in the specifications.  I receive also a request regarding the xml.xsd.

The Parliament  want to store the current identifier (technical identifier) in the xml:id attribute.  So they ask if it is possible to have the official standardized version of xml.xsd with Akoma Ntoso and not the current troncated version of it. 

I think that it is a good idea to ensure that the akoma ntoso attributes are used strickly as specified.

1. Comments in the schema (prescriptive)

1.1. For the element FRBRmasterExpression
If the FRBRmasterEpression is specified, but without a href pointing to the masterExpression, it is assumed that NO master _expression_ exist in reality, but an UR-_expression_ exist, whose ids are used in this _expression_ as wIds. In this case, the refersTo attribute must be used to point to an TLCConcept specifying facts about the UR-_expression_.

the attribute "refersTo" does not exist for the element <FRBRmasterExpression>.  

So, I propose to remove the sentence "In this case, ... " in the documentation of the schema, so that the schema has no need to be changed.
NB: Inside the "body" of the document, the "refersTo" is already used for other purposes and cannot be reserved for this technical information. 

1.2. For the elements old and new
Comment for <old> in the schema
The element old is a metadata element containing (in some non-managed form) the old text of the modification. Attribute href points to the eId of the element new it is being substituted by.
Comment for <new> in the schema
The element new is a metadata element containing (in some non-managed form) the new text of the modification. Attribute href points to the eId of the element old it is substituting.

This is in contradiction with the content of deliverable 1 (vocabulary)
"<old>: it provides the idRef of the quotedText or quotedStructure where to find the old text "

I propose to change the two comments in the schema as they are not conform to the examples we provided until now, even in the deliverable 1

NB : "idRef of" must be changed into "reference to"

2.  Deliverable 1 : vocabulary

2.1 In the section (activeModifications)

In the explanation of textualMod, the explanation of attribute @exclusion in the introdution has two problems :

  • This text   (applying the modification in a negative manner) is not compatible with the example of "repeal with exception" (there are exceptions)
  • The destination has two different meanings : the place of the modification (usual) and the place of the exception to the modification (explanation of texualMod on exclusion);

Proposal : remove the explanation of the textualMod on exclusion

2.2 In section restrictions
The first example is false : the value of href is syntactically invalid (definition is xsd:anyURI)

Proposition : remove the example

2.3 In section 5 Basic Akoma Ntoso building blocks
For collectionBody, remove the sentence "It is possible to have some description or introductory sentences between each document. For this purpose, we have the <interstitial> element"  : it is not more true as the interstitial is now in a specific component.

Proposal : remove the text

2.4 In section 5.8.2 Referring to precise concepts in the document
mod element contains at least one ref element identifying the destination of the modification

It is not true as the reference can be in a block different than the block where the mod is

Proposition : remove "at least"

2.5 Akoma Ntoso document types - Portion Structure - example
The example is on the fragmenting of a very long text (US Code). 

The fragmentation is on two levels : 

  • First on the basis of the higher structure of the US Code , the title. 
  • Second, inside a title, on an arbitrary element (the chapter 3).

Here, it is a more philosophical discussion, as I don't really know the US legislation.
It exists two elements for the fragmentation : documentRef for split at the level of the Work/_expression_ and componentRef for split at the level of the Manifestation.

If it is clear that the split on chapter 3 is a split at the level of the Manifestation. 

But I really wonder if the split on the title is not a documentRef:

  • it is systematic, every title is a specific akomantoso instance
  • if I see the uri, the titles have uri for the work and the _expression_, and not only for the manifestation; and the place of "title 1" is not after the ~ so it is not considered as a portion. 

If I am correct, then theUS Code is a documentCollection with one documentRef per title.
The uri of the title can be /akn/us/usc!title_9!main or /akn/us/usc!title_9  (more conform to NC than ="/akn/us/usc/title_9!main)
and the uri of chapt 3 is
akn/us/usc/eng@2013-07-26!title_9!main~chp_3.xml ou
And the example is on an componentRef in a document of a documentCollection.

Attached, you have the new version of deliverable 1 - Vocabulary with, as track change, only my changes (I accept all the previous changes before I work).

Kind regards


Véronique Parisse

AUBAY Luxembourg

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


Attachment: akn-core-v1 0-csprd01-part1-vocabulary-wd18-1-vp.docx
Description: akn-core-v1 0-csprd01-part1-vocabulary-wd18-1-vp.docx

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