FW: Globally Agreed Definitions for Individual Semantics

[John McClure <hypergrove@olympus.net>]

Brian said:
The only thing I would change is
	<Document name="TransportContract">
to
	<TransportContract>
I believe the schema will be much better in that you can have a specific
schema for a TransportContract document rather than a schema for Document
that must be able to specify the union of all documents.


Brian,
The DCN places any reference to a dictionary entry into a 'name' attribute
on a resource-element; the entry's base classes are specified as its
element-type name and xsi:type value, respectively. Your suggestion breaks
that model. The DCN model is a good model catering to the needs of
object-oriented software, specifically designed to support semantic
processing on the one hand while being optimized to support standard
stylesheet processing. It is particularly mindful of the performance of o-o
software by indicating the class of the resource object that should be
instantiated, without a time-consuming dictionary-lookup. In the encoding
required by the DCN, the taxomony is carried directly in the instance
document's elements as so:

(1)	<Document xsi:type='ProductDocument' name='TransportContract'>

Say that XML/OO software is categorized as DTD-aware software, XSD-aware
software, or RDF-aware software, depending upon the type of dictionary which
it uses to resolve to a name of an object class. XSD-aware parsers equate

(2)	<ProductDocument name='TransportContract'>

with (1), so it can be encoded either way by a publisher. An RDF-parser
equates

(3)	<TransportContract>

with elements encoded either as (1) or (2). For an example of how important
this is in areas beyond object instantiation, consider the mechanics of a
stylesheet template. If ebXML standardized on (3) as you suggest, then the
template is

(4)	<xsl:template match='TransportContract'>

That's it. No alternatives with today's DTD-aware stylesheet processors.
However with the taxonomy specified in the document instance's elements,
then _three_ templates can be written, appropriately cascaded within the
stylsheet, each having its own behavior defined by the application. These
three can be written today, not some uncertain date in the future when more
muscular parsers become the norm. I maintain that these three templates
represent a pretty-darn basic organization for one's transform code,
particularly whenever in receipt of unknown document-types in the
datastream:

(5a)	<xsl:template match='Document'>
(5b)	<xsl:template match='*[@xsi:type="ProductDocument"]'>
(5c)	<xsl:template match='*[@name="TransportContract"]'>

When stylesheet engines become XSD-aware, a datastream can be coded as
either (1) or (2), and any transforms already coded as (5a)-(5c) behave
correctly, ie as if they were coded as:

(6a)	<xsl:template match='Document'>
(6b)	<xsl:template match='ProductDocument|*[@xsi:type="ProductDocument"]'>
(6c)	<xsl:template match='*[@name="TransportContract"]>

Similarly, when stylesheet engines become RDF-aware, then the correct
template would be invoked regardless of whether the datastream is coded (1),
(2), or (3), as if the templates were coded as:

(7a)	<xsl:template match='Document'>
(7b)	<xsl:template match='ProductDocument|*[@xsi:type="ProductDocument"]'>
(7c)	<xsl:template match='TransportContract|*[@name="TransportContract"]'>

[As sidenotes, RDF-aware processors also accommodate conventions concerned
with how a resource's attributes can be coded, conventions *very* handy to
developers. Further, the DCN's XSD establishes the 15 resource-types as
abstract XML element-types, all extending/subtyping the <rdf:description>
element. The set of xsi:type attribute values equates to the set of concrete
XML element-types defined in the XSD.]

To recap, I have demonstrated that your suggested encoding can yield the
same results as DCN encoding, depending on the parser. Second, the DCN
encoding accommodates more best-practices during development of
object-oriented software and of stylesheet software. Third, DCN encoding
preserves backwards-compatibility of stylesheets already written, as
datastreams evolve over time to take advantage of more powerful tools coming
onto the market.

You express concern that the "Document (class) must be able to specify the
union of all documents." I haven't experienced a problem identifying a set
of attributes that are applicable to documents as a class of resource --
these are memoralized as the content model for the <Document> element-type,
as follows, in addition to a few other attributes declated in its object
model:

<!ENTITY % baseResCM "Metadata|list|alias|description|identifier|instant|
  insert|period|initials|issue|note|quality|sensitivity|status|title">

<!ENTITY % baseAttlist "
	xmlns:xsi CDATA #FIXED 'http://www.w3.org/1999/XMLSchema-instance'
	xmlns:rdf CDATA #FIXED 'http://www.w3.org/1999/02/22-rdf-syntax-ns'
	xmlns:xll CDATA #FIXED 'http://www.w3.org/1999/xlink'
	xml:lang NMTOKEN	#IMPLIED
	xml:base CDATA	#IMPLIED
	xml:space (preserve|default) #IMPLIED
	xsi:null (true|false) 'false'
	rdf:about CDATA	#IMPLIED
	rdf:ID CDATA	#IMPLIED
	rdf:resource CDATA #IMPLIED
	id ID #IMPLIED
	idref IDREF #IMPLIED
	asOf %dt_instant; #IMPLIED
	class CDATA #IMPLIED
	count %dt_integer; '1'
	name %dt_qname; #IMPLIED
	style CDATA #IMPLIED
	template %dt_boolean; 'false'
	voided (true|false) 'false'
	xll:href CDATA #IMPLIED
">

<!ELEMENT Document (#PCDATA | %baseResCM; | rdf:Description)*>
<!ATTLIST Document
  %baseAttlist;
  xsi:type (%baseDocumentCategories;) #REQUIRED
  type (Document) #FIXED "Document"
>

The dictionary entry for the TransportationServicesAgreement (if there were
one) might be:

<rdfs:Class rdf:ID="TransportationServicesAgreement">
	<rdfs:subClassOf rdf:resource="#ProductDocument"/>
	<rdfs:subClassOf rdf:resource="#Document"/>
	<rdfs:label xml:lang="en">transportation services agreement</rdfs:label>
	<rdfs:comment xml:lang="en">
	An agreement between a service provider and customer that outlines price,
	method of payment, pickup and delivery events, and other essential details
	of the service to be provided.
	</rdfs:comment>
	<!-- put resource properties here that are not inherited -->
	<rdf:Property rdf:resource="#serviceProviders"/>
	<rdf:Property rdf:resource="#serviceCustomers"/>
	<rdf:Property rdf:resource="#productPickups"/>
	<rdf:Property rdf:resource="#productDeliveries"/>
	<rdf:Property rdf:resource="#serviceInvoices"/>
	<rdf:Property rdf:resource="#invoicePayments"/>
	<rdf:Property rdf:resource="#serviceGuarantees"/>
</rdfs:Class>

<!-- declare the "productDeliveries" resource attribute -->
<rdf:Property rdf:ID="productDeliveries">
	<rdfs:range rdf:resource="#ProductDeliveries"/>
	<rdfs:label xml:lang="en">product deliveries</rdfs:label>
	<rdfs:comment xml:lang="en">
	The topic "Product Deliveries" identifies what is to be delivered,
	when it is to be delivered, to where it is to be delivered,
	and by whom it is to delivered.
	</rdfs:comment>
</rdf:Property>

<!-- declare the "ProductDeliveries" topic that is the range of
"productDeliveries" -->
<rdfs:Class rdf:ID="ProductDeliveries">
	<rdfs:subClassOf rdf:resource="#ProductTopics"/>
	<rdfs:subClassOf rdf:resource="#Topic"/>
	<rdfs:label xml:lang="en">product deliveries</rdfs:label>
	<rdfs:comment xml:lang="en">
	A topic concerning one or more delivery events which identifies what is
	to be delivered, when it is to be delivered, to where it is to be
delivered,
	and by whom it is to delivered.
	</rdfs:comment>
	<!-- put resource properties here that are not inherited -->
	<rdf:Property rdf:ID="deliveredEvents">
		<rdfs:subPropertyOf rdf:resource="#list"/>
		<rdfs:range rdf:resource="#Delivered"/>
		<rdfs:label xml:lang="en">events</rdfs:label>
	</rdf:Property>
</rdfs:Class>

<!-- declare the "Delivered" event object that is the range of the
list of the "deliveredEvents" resource attribute -->
<rdfs:Class rdf:ID="Delivered">
	<rdfs:subClassOf rdf:resource="#ProductEvent"/>
	<rdfs:subClassOf rdf:resource="#Event"/>
	<rdfs:label xml:lang="en"> delivered</rdfs:label>
	<rdfs:comment xml:lang="en">
	Something received that has been sent, or something handed over upon
	completion of work or completion of a specified term or condition.
	</rdfs:comment>
	<!-- put resource properties here that are not inherited -->
</rdfs:Class>

<rdfs:Class rdf:ID="Document">
	<rdfs:subClassOf rdf:resource="#DCNResource"/>
	<rdfs:label xml:lang="en">document</rdfs:label>
	<rdfs:comment xml:lang="en">
	A database of information.
	</rdfs:comment>
	<!-- put resource properties here that are not inherited -->
</rdfs:Class>

These RDFS dictionary entries allow one to *semantcally validate* the
following DCN datastream. The XSD dictionary entries address "syntactic
validation" not semantic.

<Document xsi:type='ProductDocument' name='TransportationServicesAgreement'>
   <list xsi:type="topics" name='childTopics'>
   <Topic xsi:type='ProductTopic' name='ProductDeliveries'>
	<content> here is some text describing the delivery events</content>
	<rdf:Description>
	<list xsi:type='events' name='deliveredEvents'>
		<Event xsi:type='ProductEvent' name='Delivered'/>
	</list>
	</rdf:Description>
   </Topic>
   </list>
</Document>

With an XSD-parser, the following stream could be parsed and validated.

<ProductDocument name='TransportationServicesAgreement'>
   <topics name='childTopics'>
   <ProductTopic name='ProductDeliveries'>
	<content> here is some text describing the delivery events</content>
	<rdf:Description>
	<events name='deliveredEvents'>
		<ProductEvent name='Delivered'/>
	</events>
	</rdf:Description>
   </ProductTopic>
   </topics>
</ProductDocument>

With an RDFS-parser, the following stream could be parsed and validated.

<TransportationServicesAgreement>
   <childTopics>
   <ProductDeliveries>
	<content> here is some text describing the delivery events</content>
	<rdf:Description>
	<deliveredEvents>
	   <Delivered/>
	</deliveredEvents>
	</rdf:Description>
   </ProductDeliveries>
   </childTopics>
</TransportationServicesAgreement>

Last point. If ebXML nevertheless wanted to have <TransportDocument> in its
base set of XML elements, then the issue is -- in the XML Schema Document --
what does it inherit from? Clearly, one can see that the DCN would have it
inherit from a ProductDocument element-type defined in the XSD. Most likely,
specifying the inheritance would be neglected by developers in many cases.
This bothers me alot, because generic software could not be easily written,
and certainly not software that wouldn't involve a dictionary-lookup. My
general approach is to address the problem of inheritance and taxonomies
now, before (presumably) anyone has created production ebXML software. Over
time, a tag like <TransportDocument> could be used, but only after the tools
have caught up.

Sorry for the length of this reply.
John
Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)
360-301-1102 (cell)

For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or
http://www.dataconsortium.org/namespace/DCN150.DTD.htm

For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)

-----Original Message-----
From: Hayes, Brian [mailto:Brian.Hayes@Commerceone.com]
Sent: Saturday, April 07, 2001 9:58 AM
To: John McClure
Subject: RE: Globally Agreed Definitions for Individual Semantics


John,

Nicely said.

And your example is good:
> <Document name='TransportContract'>
>    <identifier>here is the transport contract reference
> number</identifier>
> </Document>
Particularly, in that it does not do something like:
	<identifier type="TransportContractReference">#####</identifier>
or
	<transportContractIdentifier>#####</identifier>

The only thing I would change is
	<Document name="TransportContract">
to
	<TransportContract>
I believe the schema will be much better in that you can have a specific
schema for a TransportContract document rather than a schema for Document
that must be able to specify the union of all documents.

Cheers,
Brian

> -----Original Message-----
> From: John McClure [mailto:hypergrove@olympus.net]
> Sent: Tuesday, April 03, 2001 4:48 PM
> To: William J. Kammerer; ebXML Core
> Subject: RE: Globally Agreed Definitions for Individual Semantics
>
>