OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]