[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legaldocml] [legaldocml] akn-nc-v1.0-wd20
Hi Fabio,nice to know that we need to revise also the text and not only the examples because I was in trouble, during the revision of the document, with inconsistencies.
It is a excellent idea to have a BNF representation, but for now I would be happy to close documentation for opening the new short-public review step.
In meantime can you say if the following URIs are correct? So I can include them in the document for tomorrow.
/akn/sl/bill/2004-02-13/2/eng@official/official/2004-07-25 /akn/sl/bill/2004-02-13/2/eng@3/official/2004-07-25 Yours, Monica Il 10/11/2015 10:46, Fabio Vitali ha scritto:
No. The version or view part CAN be a non-date. The following part is all imprecise And wrong here and there.* The “@” character (required) * Zero or more comma-separated version identifiers as follows: – If an approved act, the version date of the Expression in syntax YYYY-MM-DD. For an Akoma Ntoso XML representation, this value must correspond to the content of element <FRBRDate> in the section <FRBRExpression> of the metadata. If appropriate, the date can be integrated with a time using values for the XSD:dataTime datatype: Thh:mm:ss±hh:mm. The difference between the local time and Coordinated Universal Time (UTC) is specified using the sign + or - followed by the difference from UTC represented as hh:mm (note: the minutes part is required). See ISO 8601 Date and Time Formats and XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2/). – If a bill, the presentation date is appropriate, or the stage in the approval process that the current draft is the result of. – If an official version number exists, the version number preceded by "ver_"…. For an Akoma Ntoso XML representation, this value must correspond to the content of element <FRBRversionNumber> * The “!” character (required only if an optional part is added) * Any content authoring information to determine the authoritativeness of the text content. This is separate and independent of the authoring information relative to the metadata and markup, which are among the features of the Manifestation (optional). For an Akoma Ntoso XML representation, these values must correspond to the content of elements in the <FRBRExpression> section of the metadata. * Any content-specification date (as opposed to validity dates) (optional).There is no mention of the view date (explained later), there is no mention of the view interval, there is no mention of the fact that dates can be composed only of a year (YYYY), etc. Also, I cannot manage more than ONE version identifier, so zero or more is, for me, impossible. I would rather write:* The “@” character (required for actual versions, see section XXX for view dates) * Zero or one version identifiers as follows: – If an approved act, the version date of the Expression in syntax YYYY[-MM[-DD]]. For an Akoma Ntoso XML representation, this value must correspond to the content of element <FRBRDate> in the section <FRBRExpression> of the metadata. If appropriate, the date can be integrated with a time using values for the XSD:dataTime datatype: Thh:mm:ss±hh:mm. The difference between the local time and Coordinated Universal Time (UTC) is specified using the sign + or - followed by the difference from UTC represented as hh:mm (note: the minutes part is required). See ISO 8601 Date and Time Formats and XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2/). – If a bill, the presentation date is appropriate, or the stage in the approval process that the current draft is the result of. – If an official version number exists, the version number. For an Akoma Ntoso XML representation, this value must correspond to the content of element <FRBRversionNumber> * Any content authoring information to determine the authoritativeness of the text content. This is separate and independent of the authoring information relative to the metadata and markup, which are among the features of the Manifestation (optional). For an Akoma Ntoso XML representation, this value must correspond to the content of element <FRBRAuthor> in the <FRBRExpression> section of the metadata (optional). * A content-specification date (as opposed to validity date) (optional, but required when the content authoring information is present).Maybe we need to be more formal. If you want I can provide a BNF representation of the whole grammar. What do you think? Ciao Fabio -- On 10/nov/2015, at 10:24, monica.palmirani <monica.palmirani@unibo.it> wrote:Dear Fabio, if it is so, we have to modify the current specifications that admits after @ not strictly a date: /akn/ng/bill/2003-05-14/19/eng@first /akn/eu/bill/directive/cnl/2013/eng@ver_second pag. 16 of this official document http://docs.oasis-open.org/legaldocml/akn-nc/v1.0/csprd01/akn-nc-v1.0-csprd01.pdf Yours, mp Il 10/11/2015 10:07, Fabio Vitali ha scritto:Dear Monica, as far as I know, there is no need for ! as the separator in the expression. This is how I implement it ( ? means optional) Expression: ( language ( '@' version | ':' view ) ( ('/' exprSource)? '/' exprDate )? ( '/' Manifestation )? )? Basically, the expression part, as a whole, is optional. If there is an expression part, it is composed of a required language and either a version specification or a view specification, one of which is required. So the first item after '@' or ':' is ALWAYS the version/view specification. Counting forward after the '@', there is an optional part, that contains BOTH the expression Source AND the expression Date. The expression date is always a date, YYYY[[-MM][-DD]] (at least a year, possibly a month and possibly a day), so it is easy to spot it unambiguously (well, we must require that the expression source does not look like a date). Working backward we can identify what is the expression source, and we are done. So the following are all possible and legal (XXX are alfabetical, 999 are numeric, you can replace '@' with ':' identically): XXX@9999 XXX@YYY XXX@9999/8888 XXX@YYY/8888 XXX@9999/ZZZ/8888 XXX@YYY/ZZZ/8888 in all these cases, XXX is the language, 9999 is the version date, YYY is the version specification, ZZZ is the expression source, 8888 is the expression date. There is no ambiguity. A similar process can be made with Manifestation elements, but counting backwards before either the '.' of the format or the '~' of the Internal separator. So no, we do not need a '!' so far, I believe. Ciao Fabio -- On 10/nov/2015, at 09:33, monica.palmirani <monica.palmirani@unibo.it> wrote:Hi Fabio, in the version put in the public review: http://docs.oasis-open.org/legaldocml/akn-nc/v1.0/csprd01/akn-nc-v1.0-csprd01.pdf the character ! is used for the optional part in the expression: "The “!” character (required only if an optional part is added)" (pag. 15/57) An example: /akn/sl/act/2004-02-13/2/eng@2004-07-21!official/2004-07-25 Here the correspondent manifestation: /akn/sl/act/2004-02-13/2/eng@2004-07-21!CIRSFID/2011-07- 15/main.akn In case of /akn/sl/act/2004-02-13/2/eng@official/official/2004-07-25 We are not able to distinguish the phase "official" to the status "official". It seems to me that we need another character. Yours, Monica Il 09/11/2015 22:49, Fabio Vitali ha scritto:Dear all, Let me try to recap the discussion. Currently the URI syntax is as follows: Work S1 [Expression] S2 [Manifestation] Sx [Internal] S4 [format] S5 [Internal] where: S1 = / S2 = / Sx = ~ S4 = . S5 = # i.e., Work / [Expression] / [Manifestation] ~ [Internal] . [format] # [Internal] Any part in square brackets can be omitted except for the Work part, and when omitted there is no need for the separator. Of course the format is a Manifestation-level feature, but for tradition it must be at the very end, so the [Manifestation] block contains all Manifestation-level features EXCEPT for the format. "Internal" is a reference to the structure within the document that is the destination of a point-to-point reference. It has been understood so far as simply the id of the individual fragment. If you put it after the #, it is a client-side specification (the server returns the whole document and the user agent scrolls to the actual position); if you put it after the ~ sign, it is a server-side specification (the server is allowed to return either the whole document or a <portion> containing only the fragment specified). If you put it after both, and have Now the necessity has arisen to specify also the component where the fragment is placed. I believe we all agree that it should be placed after the Manifestation-level features and before the format. I think we also agree that if there is a component identifier, it should be before the fragment identifier. Therefore, it should have the following organization: Work S1 [Expression] S2 [Manifestation] Sx [Component] Sy [Fragment] S4 [format] S5 [Fragment] I intentionally removed "Internal" and replaced it with both "Component" and "Fragment", because I think that "Component" is a part of the specification of the destination of a point-to-point reference just as much as the fragment id. So there is the discussion of what should be Sx and Sy. * According to myself and Monica, Internal = Component + Fragment, therefore Sx = ~ and Sy = / , as follows: Work / [Expression] / [Manifestation] ~ [Component] / [Fragment] . [format] # [Fragment] In practice, in order to obtain the "Fragment" part, you select the string between ~ and ., explode it by /, and take the last item. Three lines of code. According to Veronique, Internal = Fragment, because she has no need for Component, and therefore Sy = ~ and she does not care for Sx, possibly !, or maybe a named sequence of characters such as /c=, or whatever. Work / [Expression] / [Manifestation] Sx [Component] ~ [Fragment] . [format] # [Fragment] In practice, in order to obtain the "Fragment" part, you simply select the string between ~ and ., and you are finished. One line of code. So the big discussion is between a solution that requires one line of code and another that needs three lines. Ok. I can accept that. It bothers me that this is a bleed-to-death-rather-than-compromise situation, but I can accept that. I will personally bleed to death rather than accept a named sequence in the URI, such as /v= or /c= or whatever. I STRONGLY believe it is ugly, a mistake and a dead end. I will object to ANY decision in that direction. So in my view the final decision is between the following solutions: a) Internal = Component + Fragment, and therefore Sx = ~ and Sy = /, and you need three lines of code to get to the Fragment specification. b) Internal = Fragment, and therefore Sy = ~ and Sx = ! or maybe Sx = ;, and you need one line of code to get to the Fragment specification. I definitely prefer solution a), since I believe two more lines of code kills no-one and the result is much more elegant, but am willing to compromise on b) as long as NO TALKS OF NAMED SEQUENCES are ever brought upon us ever and ever again. In both cases we shall need to specify a "default component" specification, for the situations in which you have to specify a component, but you do not know its name and you know it is the same component as the source of the ref. In this case we have decided to use the $ sign to indicate "this component" (i.e., the same component as the reference). Thus: a) A few examples: - /akn/eu/act/2015/123/fr@/eupub~art_12.akn#art_12 (Art. 12, no component specified) - /akn/eu/act/2015/123/fr@/eupub~main/art_12.akn#art_12 (Art. 12 of main component) - /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) - /akn/eu/act/2015/123/fr@/eupub~$/art_12.akn#art_12 (Art. 12 of this component) or b) - /akn/eu/act/2015/123/fr@/eupub~art_12.akn#art_12 (Art. 12, no component specified) - /akn/eu/act/2015/123/fr@/eupub!main~art_12.akn#art_12 (Art. 12 of main component) - /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) - /akn/eu/act/2015/123/fr@/eupub!$~art_12.akn#art_12 (Art. 12 of this component) Shall we vote? I vote proposal a). I will sigh but will not object to proposal b). I will sigh and consider proposal b) with a different choice for Sx. I will strongly object to ANY OTHER PROPOSAL and bleed to death. Ciao Fabio -- On 05/nov/2015, at 10:34, "PARISSE, Véronique" <V.PARISSE@aubay.lu> wrote:Dear Monica, A very first reaction to your document. Initially, the naming convention in akoma ntoso use the http "#" to introduce the local information after the IRI (portion information). But the # has a special usage, it is a request for a part, client side, so the information after the "#" is never sent to the server. This is a problem and the solution we found in end of 2014 was to replace the "#" with the "~", without any other change. So, for example, the reference /akn/sl/act/2004-02-13/2/eng@2004-07-21#chp_3 has as equivalent syntax /akn/sl/act/2004-02-13/2/eng@2004-07-21~chp_3 where everything, including the local information are sent to the server This usage can also be done on the iri relative to a work : /akn/sl/act/2004-02-13/2#chp_3 /akn/sl/act/2004-02-13/2~chp_3 or to an expression... of course, you can refer a local position to the current document with "#chp_3" and with the alternative syntax, "~chp_3". This syntax is used intensively at the EP, the Commission and starts to be used at the OP (Publication Office). Now, if you consider that the ~ is a beautiful character that you want to use for another usage, please, replace it with another character for isolate the local part (for example "$" as you use it when the local info is alone) so that we have /akn/sl/act/2004-02-13/2$chp_3 /akn/sl/act/2004-02-13/2/eng@2004-07-21$chp_3 or $chp_3 The important requirement is that the syntax remains with the same structure as the one with the "#" and allows to separate quickly the local information from the rest of the iri. For the rest of the document, I will examine it in the next days and provide some concret examples from the european institutions to be sure of my understanding. 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 5 novembre 2015 1:48 À : legaldocml@lists.oasis-open.org Objet : [legaldocml] akn-nc-v1.0-wd20 Dear LegalDocML, please find the last version of the akn-nc-v1.0-wd20. The next meeting (Nov. 11, 2015) it is important to have the quorum for approving this document. After this approval we can update also the D1. Yours, Monica ------------------------ Modifications: 1. COMPONENT AND FRAGMENT /akn/it/decreto/ministero-salute/2012-04-18/s2124076/~allegato_1/allegato_d ~allegato_1/art_1 use [Work][@Expression][!Manifestation-optional-parts]~[Component]/[Fragment].[Format] 2. SUB-JURISDICTION /akn/it-45/act/ordinanza/regione-er/2012-06-08/1/~allegato/art_1 3. DIVISION OF MANIFESTATION using ! /akn/sl/act/2004-02-13/2/eng@2004-07-21/official/2004-07-25!fabio/2015-10-25.xml 4. Incremental syntax query decree-ministeral /akn/it/act/decree-ministerial /akn/it/act/decree 5. Local reference ~$/art_1 -- =================================== Associate professor of Legal Informatics School of Law Alma Mater Studiorum Università di Bologna C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3 I - 40121 BOLOGNA (ITALY) Tel +39 051 277217 Fax +39 051 260782 E-mail monica.palmirani@unibo.it ====================================-- 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 .-- =================================== Associate professor of Legal Informatics School of Law Alma Mater Studiorum Università di Bologna C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3 I - 40121 BOLOGNA (ITALY) Tel +39 051 277217 Fax +39 051 260782 E-mail monica.palmirani@unibo.it ==================================== --------------------------------------------------------------------- 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-- 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 .-- =================================== Associate professor of Legal Informatics School of Law Alma Mater Studiorum Università di Bologna C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3 I - 40121 BOLOGNA (ITALY) Tel +39 051 277217 Fax +39 051 260782 E-mail monica.palmirani@unibo.it ====================================-- 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 .
-- =================================== Associate professor of Legal Informatics School of Law Alma Mater Studiorum Università di Bologna C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3 I - 40121 BOLOGNA (ITALY) Tel +39 051 277217 Fax +39 051 260782 E-mail monica.palmirani@unibo.it ====================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]