Re: [legaldocml-comment] [AkomaNtosoCore-v1.0-Vocabulary] French Nationa

Subject: Re: [legaldocml-comment] [AkomaNtosoCore-v1.0-Vocabulary] French National Assembly AKN implementation

Dear Olivier,

I am not a member of the Legaldocml Technical Committee, but I have familiarised myself with the standard.

- 4.7 Custom Elements
Quoting from http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd03/part1-vocabulary/akn-core-v1.0-csprd03-part1-vocabulary.html#_Toc480551488 :
"To help bodies find the most suitable subset of the Akoma Ntoso XML schema for their needs and requirements, a web service has been created to generate custom sub-schema, that can be accessed from http://akn.web.cs.unibo.it/aknssg/aknssg.html."
It seems encouraged, then, that an organisation could restrict their own usage of Akoma Ntoso to a subset of the full schema. Whether or not this is a recommended approach, I do not know, but it seems sensible if you know in advance with a high degree of certainty that your legal documents all follow a specific pattern.

- 6.3 Hierarchical Structure :
I believe I read somewhere in the specifications that no predefined ordering between the different hierarchical containers is enforces, though I cannot find it now. I expect this is the case regardless, as different countries have different traditions for the hierarchical structures used in their legislative texts, and Akoma Ntoso attempts to be flexible enough to accommodate for all of them.

- Structure approach: an hcontainer for each paragraph ?
To me, assuming the French/relevant legal tradition actually has a term for the hierarchical level below an article, and that term is "paragraph", then Structure 1 sounds like the best approach, as this markup is more semantically detailed. Remember that <p> is not short for "paragraph" in Akoma Ntoso as it is in HTML, but rather <p> is just the default block, which text needs to be wrapped in. As such, Structure 1 specifies that the elements under the article are semantically called paragraphs, and differentiates between them; whereas Structure 2 does not name the nested structure under the article, nor does it differentiate between them. For higher structural and semantic detail, I would go for Structure 1.

Note though, that these structures also have different textual content. Structure 2 does not contain the contents of <num> elements of structure 1. Seeing as, to my understanding, the <body> of an Akoma Ntoso document should contain the textual content exactly as it was given by the relevant legal body, and enrich it only via structure but (largely) without modifying the text, then these two structures cannot both be correct. I believe the <num> elements should only be added if the actual prescriptive legal document contains numbering. If it does not, but you would still like to structurally enrich the document with such numbering, then I believe an attribute on the corresponding hierarchical container is the way to go, or a marker element if position is important.

- PDF numbering for easier navigation
See the second paragraph of my answer to the previous question. If the actual prescriptive legal document the markup manifests contains numbering, then <num> elements are the obvious choice. If not, then an attribute on the relevant hcontainer or a marker would do the trick. Remember that all hcontainers use attribute group "corereq", which allows whatever attribute you want, as long as it is from a different namespace than the Akoma Ntoso namespace.

- Misunderstanding of the use of custom attribute @id
I cannot find any of an "id" attribute in any of the most recent examples at http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd03/part2-specs/examples/ ?
However, eId attributes should follow a specific syntax, as given by http://docs.oasis-open.org/legaldocml/akn-nc/v1.0/csprd03/akn-nc-v1.0-csprd03.html#_Toc480804296 . It is used to identify elements within the document. If one needs to annotate elements with another type of identifier, with a different semantic meaning, then the eId and wId attributes should not be used for that purpose.

I hope this has been helpful, and in line with the intention of the standard.

Best regards,
Anders Thorbeck

2017-05-02 18:31 GMT+02:00 CARIZZONI Olivier <Olivier.CARIZZONI@dila.gouv.fr>:

Dear all,

I’m Olivier, developer at la DILA, a French organism responsible for publishing legislative texts and official data.

We are looking at Akoma Ntoso Schema Implementation to replace the Word authoring system of the French National Assembly (inputs are currently transmitted in word format, then converted to some complex xml).

If you don’t mind me to, I’m calling on you for some questions about the core vocabulary specification :

- 4.7 Custom Elements

We have to keep our XML valid against the global standard, but do you recommend restraining the schema for easier authoring and to fit only our needs ?

- 6.3 Hierarchical Structure :

Is there a hierarchical order to respect among the hcontainer elements listed in the table page 70 ? (eg: a section must be included in a chapter)

Or can we choose and create our own structure of hcontainer ? (for local understanding purpose)

I have some more questions not approached in this specification thus outside the scope of this email list :

- Structure approach: an hcontainer for each paragraph ?

Most of the exemples I have seen take advantage of using an hcontainer for every paragraph. I haven’t seen any recommendation about that in the vocabulary specification:

So I’d like to have your opinion between the two structures below, which would be the recommend one to you ?

Structure 1 : an article containing several hcontainer for each paragraph:

<article>

                <num>Article 1<sup>er</sup></num>

                <paragraph>

                               <num>1</num>

                               <content>

                                               <p>La division 2 du chapitre III du titre Ier du livre Ier de la deuxième partie du code général des collectivités territoriales est ainsi modifiée :</p>

                               </content>

                </paragraph>

                <paragraph>

                               <num>2</num>

                               <content>

                                               <p>1° L’article L. 2113–10 est ainsi modifié :</p>

                               </content>

                </paragraph>

</article>

Structure 2 : an article with an unique content:

<article>

                <num>Article 1<sup>er</sup></num>

                <content>

                               <p>La division 2 du chapitre III du titre Ier du livre Ier de la deuxième partie du code général des collectivités territoriales est ainsi modifiée :</p>

                               <p>1° L’article L. 2113–10 est ainsi modifié :</p>

                </content>

</article>

- PDF numbering for easier navigation

A specific need for our PDF concerns a numbering for easing the viewing of an article content:

Sometimes the numbering isn’t linear, it is provided by a tool, so we have to store and reuse the information for PDF output. I haven’t seen a tag or attribute addresses this need in the specification. To your opinion how could we implement it ?

- Misunderstanding of the use of custom attribute @id

My last question is curiosity about the use of custom @id I have seen in lots of exemples, especially those from the European parliament :

Exemple : <division id="_2012744_0015">

Why do they use custom @id instead of the attribute @eId provided ? It is because their identification method doesn’t match the one preconized for @eId attribute ?

In advance thank you for taking the time to answer me.

Some of the questions aren’t relative to the understanding of the core vocabulary document, but it would be glad of you if you can provide me with an answer. This implementation is an entry point for introducing the AKN standard in the French legal data ecosystem.

Regards,

Olivier Carizzoni

legaldocml-comment message