Hello Monica and everybody
see my comment hereafter
But before, I have something that I want to add in the specification (but we don't have the time to discussed it yesterday) :
Akoma Ntoso documents are divided into containers : <preface>, <preamble>, the main content of the document, <conclusions> and <attachments>.
The <preface>, <preamble> <attachments> and <conclusions> elements are available in all types of documents.
But the "main content of a document" is marked by different kind of elements, depending on the type of the akoma ntoso documents (the content are differently structured). For single document
(so, not a document collection), we have: <body>, <mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>.
I propose that, for all these elements (<body>,
<mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>), the Akn naming convention provide a
common prefix (for example, « body »), so that we can use it for selecting the whole body of an act
([http://www.authority.org]/akn/sl/act/2004-02-13/2~body
For the rest, see my comments below (in blue)
Kind regards
Véronique
Véronique Parisse
AUBAY Luxembourg
Orco House
38, Parc d’activités - L-8308 Capellen
Standard : +352 2992501
Fax : +352 299251
www.aubay.com
________________________________________
De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de monica.palmirani [monica.palmirani@unibo.it]
Envoyé : jeudi 12 novembre 2015 8:56
À : legaldocml@lists.oasis-open.org
Objet : [legaldocml] URGENT: Summary of Naming Convention - D3
Dear all,
thanks for the yesterday TC meeting.
I would like to summarize the decision taken and to consolidate the
pending issues in order to close the D3 remotely before the next TC
meeting scheduled Nov. 25th.
We agree on this syntax where (see the Adobe Connect minutes below):
WORK
/akn/eu/act/2015/123~art_12 - simple situation
/akn/eu/act/2015/123!main/~art_12 - main is optional
also, I don't think that the / is necessary before the ~
=> /akn/eu/act/2015/123!main~art_12
/akn/eu/act/2015/123!main/annex_1/annex_5~art_12 - complex situation
or
/akn/eu/act/2015/123!annex_1/annex_5~art_12 (main optional)
_expression_
/akn/eu/act/2015/123/fr@2015~art_12 - simple situation
/akn/eu/act/2015/123/fr@2015!main/~art_12 - main is optional
/akn/eu/act/2015/123/fr@2015!main~art_12 - main is optional
/akn/eu/act/2015/123/fr@2015!main/annex_1/annex_5~art_12 - complex
situation with components
or
/akn/eu/act/2015/123/fr@2015!annex_1/annex_5~art_12 (main is optional)
/akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12 - complex
situation with components and optional metadata of the _expression_ (eupub)
also
/akn/eu/bill/2015/123/fr@ver_final!annex_1/annex_5~art_12 (version "final" of the bill for example when a proposal for an act is adopted by the Commission)
MANIFESTATION
/akn/eu/act/2015/123/fr@2015~art_12.xml - simple situation
/akn/eu/act/2015/123/fr@2015!main/~art_12.xml - main is optional
/akn/eu/act/2015/123/fr@2015!main~art_12.xml - main is optional
/akn/eu/act/2015/123/fr@2015!main/annex_1/annex_5~art_12.xml - complex
situation with components
or
/akn/eu/act/2015/123/fr@2015!annex_1/annex_5~art_12.xml (main optional)
/akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12.xml-
complex situation with components and optional metadata of the
_expression_ (eupub)
/akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12.xml- (main optional)
Another point
For the fragment/portion, we explain
the mapping between the structure and the name used in the reference ("art" for article, "chp" for chapter, name of the element in general, how is make the numbering, ...)
For the component, we need also to specify
where we find the information (which part of metadata correspond to the name of the component (annex, appendix, schedule, ... : is it the name attribute of the akn document element ? is it the metadata subType, other ?),
We need also to explain how to design a component that has no component name
(for example, documents that are attached and not included, like the agreement attached to a decision act).
Finally, we need also to provide some examples for documentCollection (where you have two type of component : one inside the main body and one inside the attachment).
PENDING ISSUES sub-fragments:
To clarify my position
I think that it is dommage that the "/" separator is used for two type of information in the structure of the IRI
- separate different metadata (for example, in "eu/act", the slash separate different type of information ( the country and the type of the act).
- mark the hierarchy (for example, annex_1/appendix_3/attachment_2 ...)
On another point, we have another syntax for marking a hierarchy : "__" So why can we not do this :
/akn/eu/act/2015/123/fr@2015/eupub!annex_1__annex_5~art_12__para_1.xml
Alternatively, if you consider that "__" is not enough esthetic, then we can continue to use the "/" meltingpot, but EVERYWHERE, so
/akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12/para_23/list_2/point_9.xml#art_12/para_23/list_2/point_9
Consider that it is the syntax of referencing but it can never be considered as the "exact value" of the eId attribute, because, as it was clearly explained yesterday, the "eId" value is completely dependant on the organisation of the manifestation
and whether you physically group or not the component manifestations in the same xml document (in fact, eId is constained by the XML syntax and rules on the unicity of the attribute) but of course, the author of a citation has not to take this into account.
So, the naming convention of the reference is more generic and cannot be build on the real organisation of the manifestations.
Much more, the naming convention of the reference must, for my point of view, be considered as a generic syntax allowing to find information in documents independently of its format: I can use the akn naming convention to reference fragment/portion in pdf
or word document (in fact, I do it for referencing portion/fragment in a Formex document that has a completely different syntax for the naming of the text structure. So, I establish a mapping between these two syntaxes).
So, choice between the / or the __ (my preference is for the "__") but please, adopt it everywhere a hierarchy is expressed (for component hierarchy also),
Of course, we need to align the syntax of the eId accordingly (hoping that "/" is allowed for eId ;-) ).
Veronique proposal:
/akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12/para_23/list_2/point_9
Other proposal:
/akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12__para_23__list_2__point_9
Take also in consideration the fragment after the format:
a)
/akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12/para_23/list_2/point_9#art_12__para_23__list_2__point_9
or
b)
/akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12__para_23__list_2__point_9.xml#art_12__para_23__list_2__point_9
or
c)
/akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12/para_23/list_2/point_9#art_12/para_23/list_2/point_9
Please start the discussion in mailing list because I want to close all
the deliverable within the year 2015 and the correspondent
short-public-review.
It is urgent and necessary for the success of the standard.
Yours,
Monica
--------------
The Minutes of yesterday from Adobe Connect: 11th Nov. 2015
Monica Palmirani:hi Grant
Grant Vergottini:Hi Monica
Monica Palmirani:https://www.oasis-open.org/apps/org/workgroup/legaldocml/event.php?event_id=41129
parisse:hello
Monica Palmirani:hello
Monica Palmirani:Hello Fabio
Fabio Vitali:ciao
Fabio Vitali:As soon as Sylvia ecords her attendance, we have quorum
Fabio Vitali:so we can start
MonicaPalmirani:/akn/eu/act/2015/123/fr@/eupub~$/art_12.akn#art_12 (Art. 12 of this component)
Fabio Vitali:yes
Grant Vergottini:yes
parisse:yes
Monica Palmirani:- /akn/eu/act/2015/123/fr@/eupub!$~art_12.akn#art_12 (Art. 12 of this component)
parisse:but not the doc
Monica Palmirani:- /akn/eu/act/2015/123/fr@/eupub~Annex_3/Annex_1/art_12.akn#art_12 (Art. 12 of component Annex 1 of Annex 3)
Monica Palmirani:- /akn/eu/act/2015/123/fr@/eupub!Annex_3/Annex_1~art_12.akn#art_12 (Art. 12 of component Annex 1 of Annex 3)
Grant Vergottini:I prefer the first
MonicaPalmirani:/akn/eu/act/2015/123/fr@/eupub~Annex_3/Annex_1/art_12.akn#art_12
Grant Vergottini:yes
Grant Vergottini:yes
parisse:[http://www.authority.org]/akn/sl/act/2004-02-13/2~art_3 with the same syntax as for the # [http://www.authority.org]/akn/sl/act/2004-02-13/2#art_3
Fabio Vitali:No Veronique, it is NOT the same syntax.
parisse:why and how the user know that ?
Fabio Vitali:For one, the # goes always at the end of the string, while the ~something comes before the format
Fabio Vitali:Second: the ~ is part of the request, the # is not part of the request,
Fabio Vitali:you can put BOTH
parisse:this is what I want to change : the ~is also always at the end
Fabio Vitali:Please no. The format is at the end
parisse:not for me
parisse:the format is at the same position as for the #
parisse:why to change ?
parisse:the only difference is that all the "string" is sent to the server
Grant Vergottini:I'm sorry if I'm coming into this late, but the # part is not part of the request - and it stripped away before it gets there. We can't change that. What's left should end in the format.
Grant Vergottini:What's the issue? It seems that a lot of it is decided by standards that come before us
parisse:yes, Grant, it is the reason I propose to replace the # by the ~when you want that all the "string" is sent to the server
Monica Palmirani:The parser is not able to distinguish univocally the optional part of the _expression_ to the components
parisse:I dont understant this
parisse:Which example ?
Grant Vergottini:In my existing implementation, I do {doc}{@expressionpart}/{fragmentPath}.{format}#{id}. The only difference I can see from Fabio's proposal is that I use / instead of ~
Monica Palmirani:!
Fabio Vitali:Veronique, in the mail I gave also a brief specification of the algorithm necessary to extract the fragment id part from the URI. It is literally three lines long.
parisse:I propose also something for annex of annex. And also, I thing that the ! is also free. Last, I don't understand why the format is sometimes at the end and sometimes not.
Fabio Vitali:It is ALWAYS at the end of the request.
Fabio Vitali:as with any decent-looking URI
parisse:so #art+*.doc ?
Grant Vergottini:The format is always at the end in my case. The part starting with # is not part of the request
parisse:srry #art_12.doc ?
Fabio Vitali:#art is NOT part of the request
Fabio Vitali:this is the URI syntax not me
parisse:I don't understand the difference : it is a way to specify a portion/fragment of text
parisse:the only thing is that it is impossible to sent to the server something after the # but it is all.
Fabio Vitali:Veronique: there is a designed structure of the URI, that we are keeping consistent: AKN URIs look like normal URIs as much as possible, are organized in parts, and these parts make sense.
Fabio Vitali:The first part is the WORK
Fabio Vitali:The secodn PART is the _expression_
parisse:For a user given a reference, there is no need to make a difference between the two structure, there is no need to put the format at the end sometimes and sometimes not
Fabio Vitali:The third part is manifestation (minus, for tradition, the format)
Fabio Vitali:The FOURTH part is the internal specification
Fabio Vitali:The fifth part ìs the format
parisse:not minus that the question
Monica Palmirani:The internal specification can be used also with WORK and _expression_
parisse:and the last part is the fragment/portion part with a special character before (~or ! )
Grant Vergottini:I've never seen a URL that specified a format anywhere but at the end
Monica Palmirani:right Grant and so .xml#art_12
Monica Palmirani:this is the URL syntax
parisse:when you have the # how does it works ?
parisse:the format is before the #, not after
Grant Vergottini:The # is stripped away by the browser before the request is transmitted
parisse:I only want to use the same syntax, replacing the # by another character so that the server receive everything
Monica Palmirani:it doesn't work veronique
Monica Palmirani:for all the situations that we have
Grant Vergottini:If you just replace the # with a ~, you get a weird URL that isn't conventional
Monica Palmirani:right
Monica Palmirani:Veronique
Grant Vergottini:For some of my customers, they break the document up into a lot of small files, on for each section -- and then save the result in the file system It's easier to support that methodology using {docPath}{expressionPart}/{fragmentPath}.{format}
Grant Vergottini:one for each section
Grant Vergottini:That's why I use / instead of ~, but I'm not insistent on that
Monica Palmirani:please start with WORK
Monica Palmirani:/akn/eu/act/2015/123~main/art_12
Grant Vergottini:With my methodology, I can implement a document broken into pieces using the file system and no resolver -- just a normal web server
parisse:ok, but do you agree on the ~for separate the fragment/portion part from the IRI work _expression_ manifestation minus format ?
parisse:That is very important for me
Monica Palmirani:you are not able to redirect all the languages and all the versions useful for an interval of time Grant if you use only the file system
Grant Vergottini:I'm happy to use the ~ instead of the /
parisse:I can write ~main__art_12
Monica Palmirani:~main/art_12
Grant Vergottini:I understand that Monica, but not all customers require that
parisse:if main is a prefix like art
Grant Vergottini:Some customers need something really simple
Monica Palmirani:We need to serve all
parisse:no I think that you can do it using the same prefix_number (in the case of main, no number is needed)
Grant Vergottini:My methodology is as Fabio proposes, except for the ~, but I'm happy to accept the ~
Fabio Vitali:I believe that "main" should be optional. ~main/art_12 and ~art_12 should mean exactly the same thing
parisse:so ~main__art_1__para_1
Grant Vergottini:Yes, absolutely. For me it would be ~main/sec_12 == ~sec_12
parisse:@grand yes, really simple
Monica Palmirani:hold on: simple situation is simple we MUST to model also the other situations
parisse:~main__chp_I
Monica Palmirani:nooo
Monica Palmirani:I am forced to use internal id main__chp_I
Monica Palmirani:and It is not necessary
Monica Palmirani:at all
Monica Palmirani:simple solution you said
parisse:so you can use ~chap_I
Grant Vergottini:I would not include main__
Monica Palmirani:what about annex_1__annex__3__main__4
Monica Palmirani:and why do not use /
parisse:attachment_1__attachment_1__art_4
Fabio Vitali:We cannot use / as a separator in fragment ids, but we can and should use it to separate components from fragment ids
Fabio Vitali:attachment_1/attachment_1/art_4
parisse:or attachment_1__attachment_1__amin__art_4
parisse:no attachment is an element that has a prefix_number for eId or wId
parisse:so it is the same mechanism
Monica Palmirani:no
Monica Palmirani:it is not the same
Monica Palmirani:we can use / for composing the URI
Fabio Vitali:No veronique
Fabio Vitali:NO NO NO
Monica Palmirani:granularly
Fabio Vitali:you have a fragment id that is cpmposed of parts separataed by __
Monica Palmirani:and hierarchyacally
Fabio Vitali:But THAT IS THE FRAGMENT ID
Fabio Vitali:then you have the component name
Fabio Vitali:if the component name is part of the fragment id, it is alreay in the fragment id. Otherwise, you CANNOT USE __ to separate component names
parisse:yes, inside an attachment you have only one document. You can refer to it using his IRI that is in its identification part of the metadata
Fabio Vitali:otherwise we cannot find out where the fragment id starts
parisse:or using the imbrication of element and treat it like any other portion
Fabio Vitali:You are mixing up the organization of an XML Manifestation with the conceptual organization of the _expression_. The fragment ids work at the Work and _expression_ level, too.
Fabio Vitali:They should NOT depend on how you cut the Manifestation in pieces
parisse:not it is not the case as I use the <component> element for that
Monica Palmirani:you have also <portion>
Fabio Vitali:NOOOOO
Fabio Vitali:_expression_-level documents do not contain portions!
Fabio Vitali:This is only a MANIFESTATION-level trick
Fabio Vitali:you cannot use manifestation-level ids for links
Fabio Vitali:NEVER
parisse:I can reference document attached to the "root" document using the mecanism based on the element (cmp_1__[portion inside the document] or using the IRI that is specify at the level of the attachment
Monica Palmirani:this is the id
parisse:what do you do when you use art_1__para_1 ?
parisse:it is exactly the same
Fabio Vitali:NO ID should change if you return a portion of a document or the whole document
Monica Palmirani:One of the main comment of the reviewer Patrick is to divide the D3 in two parts: ID to move this part in D1 and naming convention of URI to maintain in D3 in order to not make confusion
Monica Palmirani:now we are stuck in this discussion.
parisse:yes, I agree with this, this is the reason I want a character to separe the two parts in the reference
Monica Palmirani:confusing ID with URI
Monica Palmirani:no Veronique
Monica Palmirani:you pretend to use ID in the URI fragment
Monica Palmirani:that are two different levels
Monica Palmirani:components are part of the URI
Monica Palmirani:fragment is linked to ID
parisse:part that is build on id and part that is build on identification part of the metadata
parisse:this is the meaning of the ~ for me
parisse:but any other character is also good
Monica Palmirani:/akn/eu/act/2015/123!main~art_12
Monica Palmirani:what about this
Monica Palmirani:veronique
Monica Palmirani:do you agree?
Monica Palmirani:with main optional
Monica Palmirani: /akn/eu/act/2015/123/fr@2015!main~art_12
Monica Palmirani:Veronique? do you agree since now?
parisse:yes that is ok for me, as it separe the identification metadata from the id based info
parisse:with only exception for the format
Grant Vergottini:And I can use /akn/eu/act/2015/123/fr@2015~art_12 if I want?
Monica Palmirani:yes
Monica Palmirani:mmmh almost
Monica Palmirani:!
parisse:yes
Monica Palmirani:!~art_12
Fabio Vitali:no
Fabio Vitali:wait
parisse:~art_12 (means, no info for the identification part)
Fabio Vitali:IF we decide to separate compnents from fargment ids, then if there is no component spec, there must be no component spearator
Fabio Vitali:So:
Fabio Vitali:/akn/eu/act/2015/123/fr@2015~art_12
Monica Palmirani:great
Fabio Vitali:/akn/eu/act/2015/123/fr@2015!main~art_12
parisse:~art_12.doc (with the only exception of the format)
Fabio Vitali:/akn/eu/act/2015/123/fr@2015!main/annex_1~art_12
Fabio Vitali:/akn/eu/act/2015/123/fr@2015!annex_1~art_12
Fabio Vitali:etc
Fabio Vitali:main is ALWAYS optional
Monica Palmirani:ok now manifestation
Fabio Vitali:manifestation level features come BEFORE the component, except for format, which is at the end
Grant Vergottini:So much complexity!!!!!!!!
Fabio Vitali:why?
Grant Vergottini:!@^#$@
Fabio Vitali:there is no complexity, there is additional information
Fabio Vitali:the URI does NOT change for documents without components
Grant Vergottini:The problem is trying to explain this to people
Fabio Vitali:Grant: you do not need this complexity until you actually need it.
Fabio Vitali:Then the users themselves will ask for complexity
parisse:I think that it must be mapped to the identification part of the document that is the attachment or the component
Fabio Vitali:I believe we do not need TWO characters, and I believe ~ is enough for both component and fragment
Grant Vergottini:The complexity should only become necessary when the situation arises where you need it. Otherwise, to the user, it appears as unnencessary
Fabio Vitali:but if this cannot be reached, then I am fine with two characters, AS LONG AS format goes to the end
Fabio Vitali:In this proposed situation, complexity does not arise unless you have complex documents
MonicaPalmirani:/akn/eu/act/2015/123/fr@2015!annex_1~art_12.xml what is the rpoblem with that?
MonicaPalmirani:/akn/eu/act/2015/123/fr@2015~art_12.xml
Monica Palmirani:simple case
Monica Palmirani:nothing more
Grant Vergottini:I'm good with that
Fabio Vitali:I can live with it
parisse:/akn/eu/act/2015/123/fr@2015!annex_1!annex_3~art_12
Monica Palmirani:noooo
Monica Palmirani:/akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12
Fabio Vitali:ONE !
Fabio Vitali:If you have a complex hierarchy of components, you use /
parisse:/akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12
Fabio Vitali:NOOO
parisse:one syntax, but different separator
Fabio Vitali:/akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12
Monica Palmirani:why veronique you have this need ? it seems to me that is a problem of tool
Monica Palmirani:in your syntax I can say /akn/eu/act/2015/123/fr@2015!annex_1/annex_3 using the natural hierarchy of URI
Fabio Vitali:I need to go now. I vote in favor for the current syntax. Please record this. I am not particularly willing to make any additional compromise
parisse:In the first part of the IRI, the / separe different information ; in the component part, it is used for hierarchisation. But we have already __ for that
parisse:so for me /akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12 is more clean
Monica Palmirani:current syntax is a big concept Fabio .... what is the current syntax
Monica Palmirani:Veronique you are mixing different syntaxes and using / it is for sure more clear for the user
Grant Vergottini:The __ is only used for assembling an identifier. I don't think if should be used to concatenate identifiers as well.
Monica Palmirani:Right! Grant
Monica Palmirani:so Veronique
Monica Palmirani: /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12
parisse:it is not concatenation, it is hierarchisation
Monica Palmirani:__ is not a hierarchisation
Grant Vergottini:__ is for concatenation, / is for hierarchisation (is that a word?)
Monica Palmirani:please consider that the people want to compose the URI using granular parts /
Monica Palmirani:ok it is clear
Monica Palmirani:I would like to vote a syntax
Monica Palmirani:we MUST go in public review
parisse:for the component ? yes : the annex 3 of the annex 2 is the same as the paragraph 3 of the article 2
Monica Palmirani:soon
Monica Palmirani:no
Monica Palmirani:annex 3 and annex 2 are not like paragraph 3
Monica Palmirani:so if there are no other important objections in term of use-cases I would like to vote
parisse:or /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12/para_1
Monica Palmirani:MOTION: /akn/eu/act/2015/123/fr@2015!main/annex_1~art_12 with main optional; /akn/eu/act/2015/123/fr@2015!main/annex_1~art_12.xml for manifestation
Grant Vergottini:+1
parisse:+1
Monica Palmirani:+1
parisse:Do you prefer /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12/para_1 or /akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12__para_1
Grant Vergottini:I think Fabio's vote is implied?
Monica Palmirani:yes
Monica Palmirani:FABIO:+1
Monica Palmirani:APPROVED.
Monica Palmirani:thanks
parisse:Do you prefer /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12/para_1 or /akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12__para_1
Grant Vergottini:First one
Grant Vergottini:But I must go now. My next meeting starts in 3 minutes
Monica Palmirani:me too
parisse:ok, we replace everywhere __ by /
Monica Palmirani:noo
Monica Palmirani:art_12__para_1
Monica Palmirani:is the internal id
parisse:yes see the answer of grant
Grant Vergottini:__ for internal Id
Monica Palmirani:we need to discusse
parisse:it is not logical
Monica Palmirani:yes it is
Grant Vergottini:Ok. next time. Biut I really must go no
Grant Vergottini:now
Monica Palmirani:because you distinguish component to the internal fragment of the document
Monica Palmirani:next
Monica Palmirani:next is 25
Monica Palmirani:please prepare also the invoices
Monica Palmirani:Grant and Veronique
parisse:you use the same / for hierachisation and separation of information : akn/eu is not the same as annex_1/annex_2
Monica Palmirani:no the annex are component and _para is fragment
Monica Palmirani:Next time 25 nov.
Monica Palmirani:Invoices please
parisse:in the first part, it is separation of information, in the second part, it is hierarchisation of component
Monica Palmirani:bye
Monica Palmirani:we will discuss the next time the art_2__para_1
parisse:can you give more info on the invoice I can do ?
Monica Palmirani:or art_2/para_1
Monica Palmirani:yes by email
parisse:fine
Monica Palmirani:ok thanks
Monica Palmirani:ciao
.
---------------------------------------------------------------------
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