Comments re:ebXML Naming Standards

[John McClure <hypergrove@olympus.net>]

Line
92. Introduction. Where is the data-model for a dictionary and a
dictionary-entry? It seems odd to have a document whose topic is the
definition of just one property of a dictionary-entry, namely its name. (Oh,
I just noted that it also mentions a few others -- Definition, a list of
synonymous business terms, and maybe some more -- so why not just cut to the
chase and define the data model (the so-called meta-model) for a dictionary
entry?

93-94. Neither the first sentence nor the entire paragraph says exactly what
is in the dictionary. I can see by implication that the dictionary contains
terms and aggregates. But terms for WHAT? What are these terms you're
putting into the dictionary? I suggest unequivocably that two sets of terms
are defined in the dictionary: resource-types referenced by commercial
transactions, and their properties. These are two separate lists of terms.
"Resources and their properties" is the language of your intended audience
(business domain experts and technical experts) while "data elements and
aggregates" is the language used when we experts talk to funding sources.

Maybe explaining the relationship between an "aggregate" and a "resource"
will suffice, but it would be best overall to use modern terms, not old
terms that have been pushed aside. In my book, an 'aggregate' is NOT a
synonym for an object-class, or a resource-type.

94-95. The standard is adapted to the ebXML design methodology or
architecture, not an "environment". An 'environment' is normally comprised
of tangible, interacting, things.

102. "Object Class" should be "Resource Class" because objects per se are
not being defined -- IDL is used to define object classes, not this
dictionary. If you insist, though, then please share something about the
SUPERCLASSES that are normally specified for every class.

102. It NORMALLY consists of Representation Type. There are examples where
representation type is implied, e.g., Identifier. In fact, I would further
suggest that representation type be made an optional part of the name to the
extent that the type is implied or explicitly given by the term's entry in
the dictionary.

So, I suggest there is just two lists of entries: (a) named resource-types,
e.g., "Account", and (b) named attribute-types e.g., "Identifier".
Attribute-types can be associated with resource-types on-the-fly via a
dotted-name, eg <Business.LegalName> and explicitly in the dictionary itself
(hint: see the <rdf:domain> element). With the right software,
<Business.LegalName> is equivalent to <Business><LegalName>. By persisting
with the (out-moded) idea that the names of all entries have to be qualified
by the name of the resources for which they are properties, such a simple
technology as dotted-names is confounded. One gets
<Business.BusinessLegalName> and <Business><BusinessLegalName>, which are
both just horrible. The reason I say 'outmoded' is that W3C/RDF technology
says that "an attribute can be associated with any resource-type, even after
the fact of the resource-type's definition". Thus, the name of the
resource-type definitely should NOT be a constituent of the name of an
attribute-type (i.e., property-type).

105. Re-title as "Dictionary Entry Definition" to match "Dictionary Entry
Name" above.

106. "that entry". This para is about the definition of a dictionary entry,
so it is very confusing to say "It shall use a structure that allows that
entry to be easily distinguished between the following: Object Class, the
Property Term, and its Representation Type."

112 - 117. Your examples show that "Number" is a synonym for "Identifier".
If a dotted-name notation was used, that single association would stand for
all those that are your examples, plus the hundreds more that are inevitable
given your current approach. Also, instead of "Business Term" why not just
use the common term "Synonym"... that would short-circuit all the questions
about whether something is a business term or a dictionary term. What a
messy discussion!

172-173. "The components of a Dictionary Entry Name shall be separated by
dots and a following space character" -- Remove entirely if composite names
(ie dotted-names) aren't put into the dictionary, as I suggest. In no event
should there be ANY spaces in a name, whether before or after a period. If
you insist, then at least justify both these sub-rules, and eliminate the
space in the name (but not it's English title).

I could go on, but my perspective on dotted-names is sufficiently at odds
with your present approach that it would be useless. Here's my story for
this. In the game of Contract Bridge, there are just 15 words that may be
spoken during bidding, with a few more that represent specific sequences of
bids (e.g., the Blackwood Convention). But there are 15! sequences of bids.
So, your present approach is to put 15! names into the dictionary, while
mine is to put just the 15 plus the conventions. Beyond that, it's rules of
the road -- you see, I think that's how society EVOLVES the "best" bidding
system/style, by defining the pieces of the game, and then letting people
combine them experimentally and experientally to optimize their outcomes.

Good luck,
John McClure
Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)