[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legaldocml] Having the cake and eating it too - menager chevre et choux - avere la botte piena e la moglie ubriaca
dear Veronique, On 19/feb/2016, at 12:54, PARISSE, Véronique <V.PARISSE@aubay.lu> wrote: > Dear Fabio, > > Thanks very well for your mail and your proposal that seems really very attractive :-) . > > I will read it carefully this week, but in the meantime, I have a small technical question to be sure to well understand your proposal : > > You say that > > DO > * If the IRI of the base document is "/akn/eu/act/2013-02-05/123/!main", > then the reference "<ref href="~art_5">see article 5</ref>" > is CORRECTLY resolved to "/akn/eu/act/2013-02-05/123/~art_5". > > DON'T > * If the IRI of the base document is "/akn/eu/act/2013-02-05/123", > then the reference "<ref href="~art_5">see article 5</ref>" > is INCORRECTLY resolved to "/akn/eu/act/2013-02-05/~art_5", > which means NOTHING. > > > Can you tell me what is the result of the following cases (if it is possible) ? > > * If the IRI of the base document is "/akn/eu/act/2013-02-05/123/", > then the reference "<ref href="~art_5">see article 5</ref>" > ??? The resolution is /akn/eu/act/2013-02-05/123/~art_5, but /akn/eu/act/2013-02-05/123/ is NOT a valid Work-level URI. In fact the slash at the end indicates that it is an Expression-level URI. A very strange Expression-level URI, but not a Work level URI. The two required parts is an Expression level URI are language and version specifications. You can omit then, and this means "undetermined" for language and "today" for version. So basically something ending with / is a peculiar Expression level URI that means "today's version in any language you have". But it is NOT a Work level URI. > To reference an annex, can I do ? > > * If the IRI of the base document is "/akn/eu/act/2013-02-05/123/!main", > then the reference "<ref href="!annex_1~p_5">see paragraph 5 of annex 1</ref>" > ? is resolved to "/akn/eu/act/2013-02-05/123/!annex_1~art_5". > yes. Ciao Fabio -- > > Thanks in advance for your answer > > Have a nice weekend > > 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 Fabio Vitali <fvitali@gmail.com> > Envoyé : jeudi 18 février 2016 15:00 > À : legaldocml@lists.oasis-open.org > Objet : [legaldocml] Having the cake and eating it too - menager chevre et choux - avere la botte piena e la moglie ubriaca > > Dear all, > > I think I found a way out of the discussion we had yesterday that can satisfy all needs. But this message is long and complex, so please find the time to read it through and digest what is inside with calm and attention. > > I spent a bad night thinking and thinking. Basically, this is how I see the issue we were discussing yesterday, as the clash between two requirements: > > (1) Maintain akn naming convention well within the boundaries of HTTP-based URI references, so that the sentence at the beginning of 4.2 of the Naming convention is correct: > > "At all levels, the Akoma Ntoso IRIs belong to the http:// scheme and are normally resolved using mechanisms widely available in browsers and web servers. Within documents, IRIs are used as references to addressable resources, and are thus called IRI references." > > (2) Allow references to components and fragments to have a compact syntax, so as not to repeat all the parts of the document they are contained within. This requirement is trivially guaranteed by the "fragment" part of the http URIs (the part starting with #), but this has the characteristics of not implying a server-side request, so that one must always deliver the full document when requested, and it is not possible to work with partial requests. > > After thinking about it long and wide, I see a solution that maintains both requirements. It requires (yet another) modification to the syntax of the Naming Convention, but I believe it could be working. > > First things first: RFC 3986 [1] defines both the basic concepts [section 4.1) and the resolution algorithm (section 5.2) for URI references. We cannot go outside what's specified here if we strive to maintain compatibility with the web, requirement (1). > > How does the World Wide Web work? Let's go out of the narrow Akoma Ntoso syntax, and let's take a generic URI reference x, for instance "abc/def.html" > > In order to resolve this reference, we need to have a base absolute URI y, which is often the full URI of the document where the URI reference x is placed, for instance "http://www.domain.com/zyx/wvu.html";. The algorithm says that the resolved full URI z corresponding to the URI reference x must be constructed as follows: > > * Use the protocol component of the base URI y > * Use the authority component (domain + port) of the base URI y > * If the path component of the URI reference x starts with "/" > * Use the path component of the URI reference x > else > * Merge the path component of the base URI y with the path component of the URI ref x > * Use the query component of the URI reference x (if any) > * Use the fragment component of the URI reference x (if any). > > Therefore, the point is in the actual meaning of the verb "merge". This is explained in section 5.2.3 of the RFC 3986 as follows: > > "return a string consisting of the reference's path component appended to all but the last segment of the base URI's path (i.e., excluding any characters after the right-most "/" in the base URI path, or excluding the entire base URI path if it does not contain any "/" characters)." > > This means that we must remove the last fragment of the path of y and append the full path of x, as follows: > > http://www.domain.com/zyx/[wvu.html] + > abc/def.html = > http://www.domain.com/zyx/abc/def.html > > If the URI reference starts with "/", on the other hand, NO merge can take place. Also, the ONLY way to have this effect is to use "/" as the separator. This is necessary. > > So in order to reach requirement (2) while maintaining (1), there is a solution, as follows: > > 1) The Naming Convention already defines the concept of "global" and "local" URI references as references starting and not starting with "/". We haven't explored the thing further, though. It is now time to do so. > 2) We keep on using global URI references as we have so far: something that starts with "/akn/" etc.. A global URI reference requires all the bits of the Work, the Expression and Manifestation as usual. It does NOT require the specification of a component or of a fragment. > 3) NEW SYNTAX: The component and fragment part of the URI reference are separated by a "/" as well as by the specific character, as follows: > /akn/eu/act/2013-02-05/123/!schedule_1 > /akn/eu/act/2013-02-05/123/!schedule_3~art_3 > /akn/eu/act/2013-02-05/123/~art_5 > > 4) NEW SYNTAX: We define a "local" URI reference as a URI reference NOT starting with "/" and containing ONLY the component and/or the fragment part of the global URI reference, as follows: > !schedule_1 > !schedule_3~art_3 > ~art_5 > > 5) We decide that a document can contain "local" URI references IF AND ONLY IF the base (e.g., the current document) already uses the component and fragment part. The behavior of using a "local" URI reference in a situation where the base does not include the component and fragment part is unspecified and usually leads to odd and unpleasant effects. > > Therefore, if the base URI is, say, /akn/eu/act/2013-02-05/123/!main, then > !schedule_1 resolves to /akn/eu/act/2013-02-05/123/!schedule_1 > !schedule_3~art_3 resolves to /akn/eu/act/2013-02-05/123/!schedule_3~art_3 > ~art_5 resolves to /akn/eu/act/2013-02-05/123/~art_5 > > which is what we wanted, requirement (2). > > Let me also point out this: > > References /akn/eu/act/2013-02-05/123, /akn/eu/act/2013-02-05/123/!schedule_1 and /akn/eu/act/2013-02-05/123/~art_5 are resolved to three DIFFERENT documents: different URIs, different Works, different XML, different everything. > > The first, "/akn/eu/act/2013-02-05/123", is resolved to a full document containing the full content of act 123: > > <akomaNtoso> > <act> > ... > </act> > </akomaNtoso> > > the second "/akn/eu/act/2013-02-05/123/!schedule_1", is resolved to a document collection containing the requested component: > > <akomaNtoso> > <documentCollection name=""> > <meta> ... </meta> > <collectionBody> > <component> > <doc name="Schedule 1"> > <meta> ... </meta> > <body> ... </body> > </doc> > </component> > </collectionBody> > </documentCollection> > </akomaNtoso> > > while the third, /akn/eu/act/2013-02-05/123/~art_5 is resolved to a portion containing AT LEAST article 5 of the act (but it could contain much more than this): > > <akomaNtoso> > <portion> > <meta>...</meta> > <portionBody> > <article eId="art_3"> > ... > </article> > </portionBody> > </portion> > </akomaNtoso> > > They are three different documents. They do NOT even look similar. > > Well, then, you can use "local" URI reference only in the second and third types of documents. This means that if you plan to include "local" URI references in your documents, you must at least require the specification of the "!main" component in your URIs. You cannot leave "local" URI references in documents whose URI does not have this bit. > > Examples of DO and DON'T: > > DO > * If the IRI of the base document is "/akn/eu/act/2013-02-05/123/!main", > then the reference "<ref href="~art_5">see article 5</ref>" > is CORRECTLY resolved to "/akn/eu/act/2013-02-05/123/~art_5". > > DON'T > * If the IRI of the base document is "/akn/eu/act/2013-02-05/123", > then the reference "<ref href="~art_5">see article 5</ref>" > is INCORRECTLY resolved to "/akn/eu/act/2013-02-05/~art_5", > which means NOTHING. > > To summarize, this is how I see it: either we introduce in this way, with this new syntax and with these limitations, "local" URI refs, or we do not allow compact references of any type, and require global URI references. > > Finally: I am re-reading the Naming Convention from scratch. I do not like it very much, it seems that the prose added since it was taken from the Akoma Ntoso Release Note has little coherence and many many different styles. > > I will update it soon and let you have the result. > > Ciao > > Fabio > > [1] https://tools.ietf.org/html/rfc3986 > > P.S.: Sorry if I looked bossy and definitive, but I certainly feel strongly about (1) and would rather abandon (2) altogether than accept compromises on (1). Also, Grant, you have better get used to a bossy style, as your next President Donald Trump will certainly show plenty of proofs of that. :-) > > -- > > Fabio Vitali The sage and the fool > Dept. of Informatics go to their graves > Univ. of Bologna ITALY alike in this respect: > phone: +39 051 2094872 both believe the sage to be a fool. > e-mail: fabio@cs.unibo.it Where, then, may wisdom be found? > http://vitali.web.cs.unibo.it/ Qi, "Neither Yes nor No", The codeless code > > > --------------------------------------------------------------------- > 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 > > > -- > This email was Virus checked by AUBAY > > -- Fabio Vitali The sage and the fool Dept. of Informatics go to their graves Univ. of Bologna ITALY alike in this respect: phone: +39 051 2094872 both believe the sage to be a fool. e-mail: fabio@cs.unibo.it Where, then, may wisdom be found? http://vitali.web.cs.unibo.it/ Qi, "Neither Yes nor No", The codeless code
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]