Re: [legaldocml] Schema Review Findings

[Fabio Vitali <fabio@cs.unibo.it>]

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?

--

Il giorno 13/apr/2014, alle ore 05:19, Grant Vergottini <grant.vergottini@xcential.com> ha scritto:

> Hi Monica, Fabio,
> 
> 1) I notice that table cells cannot contain character content. That's different from HTML and a bit cumbersome. Is there a reason that the <td> element is defined to be so complex?

Yes. We are striving to align everything, even HTML elements, to patterns. Element <td> in this case is a container, and as such cannot have character content directly inside, there has to be a block in between. 

Just write <td><p>whatever</p></td> and you should be safe. 

> 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?

> 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.

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? 

> 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. 

> 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="...">Pub. 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. 

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

>> - 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). 
>> - temporarily 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 temporarily removed (e.g., for a temporary suspension or limitation of efficacy). 
>> - translated: the content of the element is present in the markup (manifestation) in a different form than in the real content of the document (expression level) because it has been translated into a different language (e.g., to match the rest of the document or because of other editorial decisions). 
>> - editorial: 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 inserted as an editorial process when creating the XML markup.
>> - edited: the content of the element is different in the markup (manifestation) than in the real content of the document (expression level) because it has been amended (e.g., to remove scurrilous or offensive remarks). 
>> - verbatim: the content of the element is present in the markup (manifestation) is EXACTLY as it was in the real content of the document (expression level) because usual silent fixes and edits were NOT performed (e.g. to punctuation, grammatical errors or other usually non-debatable problems). 
>> - incomplete: the content of the element or the value of a required attribute is NOT present in the markup (manifestation), although it should, because the missing data is not known at the moment, but in the future it might become known. This is especially appropriate for documents in drafting phase (e.g., the publication date of the act while drafting the bill)
>> - unknown: the content of the element or the value of a required attribute is NOT present in the markup (manifestation), although it should, because the author of the manifestation does not know it.
>> - undefined: the content of the element or the value of a required attribute is NOT present in the markup (manifestation), because the information is not defined in the original document, or it doesn't exist in some legal tradition (e.g. an anonymous speech cannot specify the attribute by, or some publications do not record the numbering of the items, etc.)
>> - 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.) -->
> 


> 7) I used <alinea> for a provision that I found between two <paragraphs> It doesn't seem to belong to either paragraph. Is this the correct usage? If not, what is?

An alinea is a hierarchical structure called 'alinea' in the local tradition. This does not seem to be the case in your example. I would simply use a hcontainer and invent a reasonable term for its name attribute. 

> 
> I think this is enough review for now.
> 
> -- Grant
> ____________________________________________________________________
> Grant Vergottini
> Xcential Group, LLC.
> email: grant.vergottini@xcential.com
> phone: 858.361.6738



--

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/