Re: [legalxml-econtracts] Semantic Item Reqs

["Daniel Greenwood" <dang@mit.edu>]

John, coming out of the scenario session you led on your submission, I'd
asked you for some needed clarifications and offered to help.  In order for
requirements to be acceptable under our current course, we have said they
need to be traceable back to a scenario that the TC will agree to support.
In the end the TC may choose not to support every scenario, or every aspect
of any given scenario, that has been initially presented to it.  However,
the current status of your scenario makes it hard for me to figure out what
is "in" and what is "out".  I'd asked some questions like: who are the
parties, what are the transactions they are conducting, what bodies of law
apply to those transactions and what are the use cases you envision.  At the
conclusion of the call for your scenario, you'd agreed to send along some
simple pictures and diagrams that could make the very complex and subtle
submission more grokable.  Speaking for myself, I feel a need for that
clarification on your scenario (and probably a further tightening of some of
the others, before we are done with our requirements process) before I'll
feel comfortable taking the TC to a voting stage on any given requirement.
I can clearly see at this point how a linking potential requirement could be
supported by a number of the scenarios already finalized and before the TC,
and also can see how it could be supported by the synthesized business cases
that Peter Meyer sent to the list (that work was the result of difficult
analysis and collaboration during our face to face in Sydney).  While I see
that, I don't think we'll be in a position to vote on anything (not the
linking and not the proposed requirements below) until Rolly presents the
group with a requirements document that has proposed requirements in it.
Ideally, there will be an opportunity to deal with different and severable
requirements on a vote by vote basis.  But the particulars of that process
are up to Rolly and his excellent judgment.  For now, however, I'd lke to
request:

1. That you finish up the scenario work you'd agreed to (and I continue to
stand ready to lend a hand, if you desire and it would be helpful); and

2. That you stop making specific votable requests at such a granular level
of requirements setting at this point, but instead offer your (by and large,
well thought out and impressive) suggestions to Rolly, via the list (so we
can all learn and enjoy) and let him put it all together for us to deal with
as a comprehensive whole.

Otherwise, I fear that we will waste time and spin wheels.  That I can't
allow.

As for our next meeting, we have an agenda set and I do hope that the result
of the call is a consensus on some direction.  I don't believe that we need
to have final, tailored requirements language word crafted by the Committee
for that to happen.  The back and forth, and the minutes will reflect enough
for Rolly to work with.  If text is needed for clarification or to assure we
are all on the same page, that is fine, but I believe we should keep the
discussion at a fairly high level.

Finally, I also wish to reserve a little time at the end of the meeting to
map out the finalization of the requirements setting process and the
remainder of our structural markup tentative specification process.

Thanks much,
 - Dan Greenwood.

----- Original Message -----
From: "John McClure" <jmcclure@hypergrove.com>
To: "Legalxml-Econtracts" <legalxml-econtracts@lists.oasis-open.org>
Sent: Friday, October 24, 2003 3:40 PM
Subject: [legalxml-econtracts] Semantic Item Reqs


> For discussion (to the extent permitted by the chair), here's my statement
of
> requirement for semantic info items. This is now formally proposed for
> consideration by the TC, and (likely) represents the final requirement
that I'd
> like to see on the table during our call next week. Regards, John
>
> 5. Semantic Items
> ================
> Within the structural elements for a contract, one finds text and images.
The
> text and images express certain information such as the names of the
parties and
> the date of the contract. The items of information expressed by the text
and
> images are here called "Semantic Items".
>
> o Definition: A "Semantic Item" is information that is expressed by the
> text and or images within a contract.  A semantic item fundamentally is
> one that can be named by party(s) to the contract. A semantic item has
> no structure other than the characters of the text string or the vectors
> of the image being named.
>
> A semantic item is not metadata about a contract. Contract metadata refers
to
> information that may or may not be represented within the text/images of
the
> document to which the metadata applies.
>
> A semantic item needs citability to the same extent as structural
elements. This
> means that the cited item must appear in the output stream from an
> transformative formatting process, or the input stream to any
non-transformative
> process. Accordingly, three implementations are possible:
>
> (1) a container element from the LegalXML namespace. This element
> would have a QNAMES attribute called "names". The attribute therefore
> allows multiple namespace-qualified tokens for its content. The purpose
> of this "names" attribute is, essentially, to operate as an alias for the
> container element. Two upsides: only one element to define; and, dotted-
> name notation, being intrinsically more powerful than simple camel-case
> notation, is quite appropriate in this context in that it is exactly the
type
> of
> implementation that was intended for a QNAMES attribute. This is called
> the <item names=''> alternative.
>
> (2) elements whose names correspond to the values of the above "names"
> attribute. Two downsides: an explosion in the number of elements, all of
> which have an ANY content model; and discomfort with a standard whose
> element names use a dotted-notation, though nonetheless completely
> legal XML syntax. Upsides: can form citations using the same syntax as
> proposed for the URI of all structural elements.
>
> (3) an attribute that can be placed on any element of any other namespace
> (like xml:lang). This attribute would be called "names" and would be
logically
> related to the use of the "name" attribute in XHTML, however with a clear
> semantic intention rather than locational. This attribute contains the
semantic
> name(s) appropriate to the text content of the element hosting the
attribute.
> This is called the "lgl:names" alternative.
>
> Conclusions #5
> ==============
> By having different formats for the URIs of structural elements from
semantic
> elements, there seems to be a greater chance to stablilze more quickly the
XML
> implementation of citations as they have been historically done. This
> neutralizes the advantage of separate elements.
>
> The issue with the <item names=''> alternative is that the names being
assigned
> to the text or image are essentially metadata about the text content.
However,
> metadata for an element's content is conventionally placed as an attribute
on
> the element containing the content. It is irregular to place an element's
> metadata in an attribute on its parent (containing) element. Therefore it
is
> concluded that:
>
> o The eContract Technical Specification shall implement within the
> LegalXML namespace, a globally-scoped attribute that may be used
> by contract authors to provide text name(s) for the text or images
> within their contract. This attribute is placed on elements belonging
> to other namespaces, or on any structural element(s) defined within
> the LegalXML namespace.
>
> o The eContract Technical Specification shall define a "starter-set"
> of names corresponding to core contract terms. These names shall
> be defined within the LegalXML namespace.
>
> o The eContract Technical Specification shall establish non-arbitrary
> rules and guideline during its development of a starter-set of names,
> addressing at least, the language of text strings; the measurement
> units applicable to numeric and financial values; and the format of
> date strings. The rules and guidelines must be able to uniquely name
> each of multiple values distinguishing them, for instance, by date,
> by list position, or by any other criteria relevant to the TC. Finally,
> the rules and guidelines must address considerations that apply
> when a text string corresponding to a named semantic item is not
> wholly contained with a single (structural) element.
>
> o The eContract Technical Specification shall allow names defined by
> other namespaces within the content of the "names" attribute. These
> namespaces can be either ones that relate to specialized areas of the
> law, or ones that contain names specialized to the industry to which
> the contract applies.
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/lea
ve_workgroup.php.
>