RE: English Language Tags

[John McClure <hypergrove@olympus.net>]

Martin writes:
|A better approach is to use an namespaced element within an appinfo
|component of the element's annotation, e.g.

Fine, but see below.

and
|If you really must force RDF on the scenario then put the RDF statement
|within an adjacent appinfo statement within the same annotation.

That would cerainly work, if you want such information put into the XML
Schema document in the first place. In the DCN, such metadata as 'process
specification' are placed into the RDFS dictionary(*). Why an RDFS
dictionary? So that we can _always_ pull an object class template (by a
simple transform) from the dictionary for any term defined there. So that
document validation is much faster generally, and specialized,
semantically-oriented validation tools can be given a seat at the table
beside the sytactic tools. So that structures and rules can be defined that
are not functionally dependent on element-type definitions. So that we can
more easily integrate our industry-defined terms into someone else's
encoding system, and vice-versa. So that multiple inheritance can be
applied independent of the relationships between element-types defined for
the domain. So that W3C technology is used, well, appropriately,
acknowledging that there are reasons why the W3C defined two different
schema languages ... Not everything is a nail of course.

So here's the key question: what is the element-type of the ancestor(s) of
the <appinfo> element you mention? If it is an element-type definition,
then some may be concerned that too many element-types will be defined, and
programming would be an expensive nightmare. It is that scenario -- in
particular -- that the DCN endevours to avoid and, as a result, 'only' 15
XML element-types are defined in the DCN's DTD, and 'only' 15 RDF Schema
class-types are defined in the DCN's dictionary.

In the DCN, the dictionary contains the definitions of all "qualified name"
values used by the XML elements defined for the Namespace, e.g., the 'name'
attribute defined for the 15 resource element-types. These values, i.e.,
these terms, are not defined in the XML Schema document, but are defined in
our dictionary. The DCN dictionary, for instance, contains over 5000
industry-required terms, and a publisher is able to use their own
dictionary in their published data-streams. Terms within the dictionary are
organized into categories, and these categories correspond exactly to
concrete element-types (to be) defined in an XSD document. The XSD does not
define the terms, the dictionary does!

Regards,
John

(*) Only the instance of the process specification that is the default for
a given 'name' for a process could be stored in the dictionary. Better
would be to store in the dictionary only a pointer/URI to the process spec
that is stored in an ebXML registry. BTW, have a UID or GUID property on
this process specification -- that's ok with me because it's not on the
element-type definition!

Within an ebXML document, all related process specifications could either
be instances internal to the document, or could be pointers to an external
representation. In all DCN documents, we use the rdf:resource='uri'
construct when transmitting pointer values of this sort. From your recent
memo on this topic, Martin, you have outlined how URIs and UIDs can play
together -- I'm still trying to understand it better than I do this
moment -- so it seems that a clearer path between RDF and ebXML could
emerge after all.

For more information please see:
http://www.dataconsortium.org/namespace/DCD100.pdf
http://www.dataconsortium.org/namespace/DCD100.xml
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf
http://www.dataconsortium.org/namespace/DCN150.DTD.doc
http://www.dataconsortium.org/namespace/DCN150.DTD.htm