Dear Monica, Fabio and Grant,
Please find hereafter a few brief comments on some Grant's points.
Kind regards
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 [fabio@cs.unibo.it]
Envoyé : lundi 14 avril 2014 10:12
À : Grant Vergottini
Cc : legaldocml@lists.oasis-open.org
Objet : Re: [legaldocml] Schema Review Findings
Dear Grant:
Il giorno 14/apr/2014, alle ore 09:01, Grant Vergottini <grant.vergottini@xcential.com> ha scritto:
> See below at GCV:
>
>
> On Sun, Apr 13, 2014 at 6:48 AM, Fabio Vitali <fabio@cs.unibo.it> wrote:
> Dear Grant,
>
>
> Il giorno 13/apr/2014, alle ore 00:34, Grant Vergottini <grant.vergottini@xcential.com> ha scritto:
>
> > If you remember, earlier the @id notation used dashes as separators. Tom Bruce pointed out that there are some numbers that contain dashes in the U.S. Code. That's why we went to the underscore separator. Well, I have come across the dashed values. When
I generate the @eId I get values such as sec_31-2. It turns out that this is disalloewed as an xs:NMTOKEN does not permit dashes.
> >
> > I think that it is important that the dash be preserved in the numeric part of the number. It is required for use by the resolver and its existence is the reason we use the more awkward underscore separator in the first place.
>
> Yes, we could move eIds, wIds and GUIDs from xsd:NMTOKEN to plain old xsd:strings. Would that work for you?
>
> GCV: Yes, although I would want to disallow whitespace in an id.
>
Aargh... Then the only solution is to have a regular _expression_ associated to it... How about this:
<xsd:simpleType name="noWhiteSpace">
<xsd:restriction base = "xsd:string">
<xsd:pattern value="[^\s]+" />
</xsd:restriction>
</xsd:simpleType>
This means that the legal values of this type are only strings composed of any character except whitespace, i.e., carriage return (#xD), line feed (#xA), tab (#x9) or space (#x20), anywhere in it. We could use stricter base types, such as normalizedString or
token, but this <xsd:pattern> explicitly covers those constraints as well.
> Just write <td><p>whatever</p></td> and you should be safe.
>
> GCV: I'm not keen on the "loose" interpretation of a <p>. To me a <p> is a paragraph (not in the formal legal sense, but in the written sense) and I prefer to keep that semantic intact.
I might agree with you, but I also feel that is a lost battle already.
In the European documents, there are some very complex tables with multiple paragraphs or list inside one cell.
So, this structure of cell correspond to what is defined in the current schema for publication (formex)
I don't understand what you mean by "loose" interpretation of a <p> : it is the same interpretation as when there is only one <p> inside a <content>.
> > 2) I'm still not crazy about the <wrap> element. I keep mistaking it for a wrapper rather than a concluder.
>
> Would you officially suggest <conclusion>? <wrapUp>? <end>? Or what?
>
> GCV: <wrapUp> would be acceptable to me. <wrap> comes across as a Hollywood slang reference to "wrap up" - "It's a wrap".
I'll change wrap to wrapUp and listWrap to listWrapUp, ok?
> > 3) I am having to create a <block name="heading" eid="..."> in my <note> elements that have headings. While it is a workable solution, it seems a little awkward.
You can use a <tblock> element : it allows the <heading> as first sub-element.
>
> There is a misalignment at the moment between authorialNote, which is of type subFlowStructure, and note, which is of type blocksReq. We could easily re-align them to have both become of type subFlowStructure. Would this help?
>
> GCV: Yes.
Ok. I agree.
> > 4) I find having to have an @eId on the <heading> and <content> elements to be a little heavy handed. I think they should be optional.
>
> Veronique is adamant that all parts of the document that can be destination of modifications need to have their own required ids. This would be the case for them.
>
> GCV: So why does a <num> not have a required id? A passive amendment can affect a <num> without it being a renumbering action.
These are required because they must be identified specifically : for example,
an amendment can be made on the heading alone or on the content alone (without the heading and the num).
if <num> is affected alone (so, it must be identified as the only part of text that is modified), why the action is not a renumbering even if there are no replacement ?
We actually discussed this bit on the last teleconf and you agreed... :
>> Fabio Vitali: should num have eId required?
>> parisse: for me no, the modification of the number is a renumbering
>> Monica Palmirani: the modification of num is a renumbering at the end
>> Monica Palmirani: whoo veronique we are thinking in parallel this evening
>> parisse: yes I see :-)
>> Fabio Vitali: so heading and subheading is of type inlinereq, while num of type inline?
>> parisse: yes I think so
>> Fabio Vitali: anything else? I would really like to freeze the #@§ schema
>> Grant Vergottini: Is the proposal to make @eId required on <num>?
>> Fabio Vitali: nope the proposal is to keep eId optional on num, and keep it required on heading, and make it required on subheading
>> Grant Vergottini: Ok, I agree with that
>>
Did you change your mind?
> > 5) We have something called source note or source credit. It shows up in California, Hong Kong, and the U.S. Code. It's simply a note in the form of a citation to the legislation that originated or last amended the provision. I've modeled it as follows:
> >
> > <block name="sourceCredit" eId="...">(R.S. §§ 31–33 <ref eId="..." href="" L. 104-186, title II, § 202(2)</ref>, <date eId="..." date="1996-08-20">Aug. 20, 1996</date></block>
> >
> > It this the best approach? Should it be a note? Opinions?
>
> Who is the author? If it is drafted by the same creator as the main content of the document, then it should be in the body, and not in the metadata part of the document. If it is in line with the main flow of the document, then you should probably use a different
container. If it is not part of the main flow, then it is an authorialNote, i.e., a note by the author of the content.
>
> GCV: It is a note added by the person that "executes" the amendments in a statute. Basically, it's a reference to the statute that was used to create or amend the provision. In this sense, it is an editorial note. Should it be held in the metadata?
Then yes, it must be in the metadata. Also, if you feel like being pedantic, you could have two <notes> blocks in the metadata, one storing the notes whose text come from official sources, and another whose text comes from scholars, editors or other authors.
That is legal and appropriate.
> > 6) How should I denote provisions that are shown as "omitted". This shows up both in Hong Kong and in the U.S. Code. It is often a tombstone for a provision that has been expended or spent - it no longer has any effect although it is not repealed. Similarly,
there are cases where repealed provisions are retained in the text (as repealed) for informative or editorial reasons.
>
> Use attribute status="something", where you should decide which something best matches what you mean: this is a subtle legal decision. Maybe 'ignored'? The description of the possible values of the status attribute are as follows:
>
> GCV: I've been mapping "omitted" and "repealed, but shown" to "removed". That's the closest I can get, but it doesn't feel complete. They're actually opposite situations. In the "omitted" case, the provision still exists, but it is not shown as it has no
further effect. In the "repealed, but shown" case, the provision does not still exist, but it is retained in the text for informative reasons - duly noted as repealed.
Still believe that "ignored" is your boy.
I'll rephrase "repealed but shown" as "absent in the _expression_, but present in the manifestation", which clearly fits with "removed": "the content of the element is present in the markup (manifestation) but is not present in the real content of the document
(_expression_ level) because it has been definitely removed (either ex tunc, as in annullments, or ex nunc, as in abrogations). "
I'll also rephrase "omitted" as "not repealed, but not shown", which means "present in the _expression_, but absent in the manifestation", which clearly fits with "ignored": "the content of the element or the value of a required attribute is NOT present in the
markup (manifestation) because the information exists but the author of the manifestation is not interested in reporting it (e.g., omitted parts of the document due to editorial reasons, etc.)"
----
Summary:
* add a new simpleType 'noWhiteSpace' with all whitespace omitted, and make eId, wId and GUID use it
* rename <wrap> to <wrapUp>
* rename <listWrap> to <listWrapUp>
* make <note> of type subFlowStructure just like <authorialNote>
* Please make up your mind as of the requiredness of eId in <num>
Did I forget anything?
Ciao
Fabio
--
Fabio Vitali Tiger got to hunt, bird got to fly,
Dept. of Computer Science Man got to sit and wonder "Why, why, why?'
Univ. of Bologna ITALY Tiger got to sleep, bird got to land,
phone: +39 051 2094872 Man got to tell himself he understand.
e-mail: fabio@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's cradle"
http://vitali.web.cs.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