[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]