Comments on Naming Conventions

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

The following comments relate to the draft Naming Conventions document that
came out of the Tokyo DAMSAD meeting

Re 1.1 "The definition of a Dictionary Entry shall provide the real business
use of the entry. " The definition provided in the Business Document
Vocabulary (see earlier message) should concentrate on the role played by
the information unit within a generalized business process, and not state
anything about how the information unit is to be interpreted in different
contexts that constitute a "real business use". (I like the distinction made
in 1.2, whereby the Property Name is the "distinguishing characteristic" and
object class defines the "level of use". The definition should concentrate
on defining the "distinguishing characteristic" and not the level at which
it has been applied.)

1.2 Rule 4. What is meant by the sentence "The object class and property of
such entries shall be the same."?

1.2 Rule 7. This means that where there are more than one possible
representation the vocabulary must assign two "names" - I do not think this
is really necessary. (See Account Identifer and Account Number for an
example of why this rule will be broken.)

1.2 Rule 11. This rule will require that we introduce a definitive ruling
for how spaces will be "mapped" when vocabulary names are used within XML,
which specifically forbids spaces to occur within names.

1.2 Rule 12. Some characters must be forbidden. For example colons and
forward slashes must not be used within names as they have specific meanings
within different parts of XML processing.

1.2 Rule 13. Who is to determine if DUNS and EAN are real words? You will
never find these in a dictionary. Why not XML, MP3, NATO and UNSPC. Either
we ban acronyms altogether or we cannot place any restrictions on whose
acronyms are acceptable and whose are not. (In any case, this seems to clash
with Rule 14!)

2 Boolean. XML restricts Boolean to being true or false. On and off are
specifically forbidden (they can be defined as enumerated code lists with
two permitted values), and the concept of 0 or positive has also been
rejected as being unworkable.

4 FAQ 5
Why suddenly introduce the term Subject. Up to now we have discussed Objects
and Properties and Subjects have not been explained at all.
Example 1
MaritalStatus Category Code is a bad example. It should be Marital Status
Code. (The Code records the current Status of the Marriage.)
Example 2 is also dubious. Account is the characteristic property for the
Identifier. The CashOnDelivery is a context in which this characteristic is
applied. In other words it is the Object to which the property applies.

Martin Bryan