Fw: Comments on ebXML Core Components forms

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

During their discussions on May 24th the following comments were made on the
design and use of the ebXML Core Components data capture forms, and the
associated DTDs, by the CEN/ISSS Electronic Commerce Workshop's project
group on Defining and Managing Semantics and Datatypes (DAMSAD):

The User Community fields needs to allow the definition of multiple
communities. At present there is no information as to how communities should
be identified. We recommend that this field be completed by entering one or
more codes from the UN ISIC list of standard industrial classificationns for
economic activity.

The set of Data Format Types should be extended to recognize Part 21 of ISO
10303 as an alternative way of representing the data format definition.

The association of Character Set information with data format definitions
does not seem logical. Whilst it may help to define restrictions that
applied to the creation of valid codes in previous applications, it has no
application within an XML message. The encoding used for the XML message
cannot be altered in response to the character set of any contained data
format. For example, if the character set for a data format is ISO 10646,
but the encoding of the message is ISO 8859-1 then only the subset of the
data format that is conformant with 8879-1 will be valid within the
document, irrespective of the way in which the data format has been defined.
If a document contains a reference to one data format that is restricted to
ASCII, and another is restricted to ISO 8879-1, but the default UCS2 is used
for the XML message, there is no way in which the XML schema can report
errors in the data format simply because a character outside the range
permitted for the data format has been specified. If the ebXML Core
Components group wishes such restrictions to be applicable they must first
pass this as a requirement to the W3C Schema Group to see if it is possible
for them to add such a restriction. If they do not there seems little point
in recording character set details for each data format.

In reviewing the accompanying DTD the DAMSAD group noted that while multiple
names can be associated with a description to allow for the multilingual
naming of a Pattern, Entity and Concept it is not allowed for
Representation. In addition, while the Description element, like the Name
element, has an xml:lang attribute attached to it to allow different
language versions of the Description to be defined only one Description is
allowed at any point in the DTD. Whilst the form associated with Code Set
definitions does allow the value of the language attribute to be changed for
the description of a permitted value other forms do not allow the language
of the Description to be specified, and in no case can the language of the
the name assigned to any of the definition units be change from the default
English value using the current data capture forms. Whilst recognizing that
the English version (or one particular instance if there are definitions
relevant to different industry segments or processes) should be considered
as "priviledged" as being the "master" definition of a core component, it is
felt that the DTD should allow for multiple names and multiple descriptions
to be assigned to any object that can be recorded by the DTD, even if the
data capture forms only allow a single Name/Description.  An attribute
should be added to identify one of the entries as the "master" description.
The data capture forms should allow the language used for completing all
textual fields on the form to be recorded if it differs from English.

There should be some mechanism for identifying which version of a code set
is being referenced.

Martin Bryan
Chair, CEN/ISSS DAMSAD project group