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: 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):

/akn/eu/act/2015/123~art_12 - simple situation
/akn/eu/act/2015/123!main/~art_12 - main is optional
/akn/eu/act/2015/123!main/annex_1/annex_5~art_12 - complex situation

/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/annex_1/annex_5~art_12 - complex situation with components /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)

/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/annex_1/annex_5~art_12.xml - complex situation with components /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)

PENDING ISSUES sub-fragments:

Veronique proposal:

Other proposal:

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
b) /akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12__para_23__list_2__point_9.xml#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.


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
  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
  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
  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 /
  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: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:!
  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?
  Monica Palmirani:simple case
  Monica Palmirani:nothing more
  Grant Vergottini:I'm good with that
  Fabio Vitali:I can live with it
  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 /
  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
  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
  Monica Palmirani:ok thanks
  Monica Palmirani:ciao

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