Re: XML Implementation spec

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Ernie

Congratulations on a good first draft. Some comments:

In the pargaraph on Declaring Sub-Classes of an Entity you suggest that the
best approach is to use the name of the entity being subclassed as the model
for the sub-class, e.g. <!ELEMENT Buyer (Party)>. If, instead, you consider
the model as an abstract class, you can use the model of the entity being
subclassed as the model of the containing entity, e.g. <!ELEMENT Buyer
(PartyIdentifier, Address, Contact)>. If necessary you can record the
subtyping source using a fixed attribute <!ATTLIST Buyer AbstractClass CDATA
#FIXED "Party">. Using this technique you can remove one level of tagging
from the XML message without loosing any "knowledge" from the model.

With regard to the paragraph on Declaring a Representation Class, we
discussed the roles of Representation Definitions in the ebXML Core
Components metamodel at the UK Data Harmonization Group meeting set up to
work on Core Component Definitions yesterday (May 31st). Your own examples
show where the problem lies. You cannot have a single Representation class
for things like Identifier, Code, etc. You need to have separate
representation classes for PartyIdentifier, ItemIdentifier,
LocationIdentifier, etc, otherwise you cannot constrain which data
formats/code sets apply to each context in which the generic representation
class is used. On the other hand there is no difference between an element
called AddressTypeCode and one called AddressType. Where you end up with
combinations like DepartmentNameCode and DepartmentName then you need some
form of differentiation (or you need to make the code an attribute of the
name that references a code set).

You suggest using the "Specification as given in the Concept section of the
Representation Class Definition" as the class name. You need to be careful
here about the Core Components metamodel. When we came to complete the model
and the associated forms, the Concept details were made part of the Data
Format and Code Set definitions, not part of the Data Representation Class
definition, which has a separate Data Representation Name and a separate
description (but nothing called a Specification). However, I did not intend
that the Data Representatio Name should be used as part of an element name.
It was simply a name that could be used to associate a "set" of data
representations with a particular data entity. The reason for this is that
there can be more than one data format/code list that applies. For example,
for PartyIdentifier both the EAN and DUNS identifiers apply. These could
both be defined either in terms of a data format, or in terms of a
(reference to) a list of permitted values (e.g. as limited for use in a
particular scenario). Therefore the PartyIdentifier element needs to be able
to choose from a set of recognized datatypes. This set is what is named in
the Data Representation Name field, not the individual datatypes. The set
name was not designed to be used as part of the name: it was designed to be
something that could be used to provide users with, for example, a list of
choices that could be made when designing a DTD based on the core components
that reference that data representation as a permitted format for the data
within a leaf data entity.

The names assigned to individual Data Formats and Code Sets are defined in
the Data Format Concept Name and Code Set Concept Name fields that uniquely
identify each format/code set. These are not designed to be directly
referenced as part of an data entity/element name. The idea is that they
will form the name of an XML Schema DataType definition, normally in the
form of <xsd:simpleType name="ConceptName" base="xsd:string">.... The
definition of the data entity as expressed in the element then references
this in the form <xsd:element name="EntityName" type="ConceptName"/>. The
only way you can do a similar type of indirection within a DTD would be to
have an attribute such as ebXML:datatype which could be assigned a fixed
value which was a URL that pointed to the datatype definition, e.g.
<!ATTLIST EntityName ebXML:datatype %URL; #FIXED
"http://www.ebxml.org/datatypes/EAN-Idenfier">

What I haven't had time to look at is whether it is possible to define XML
Schema complex data types that would allow multiple simple datatypes to
apply to an element. We really need some mechanism whereby multiple sets can
be identified, i.e. by using multiple URLs or by using a list in the type
field. In such scenarios the Data Representation Name could be used as the
name of the object that relates the different simple datatypes, but again I
would not expect it to form part of the element name.

Martin Bryan