RE: Comments re:ebXML Naming Standards

[James Whittle <james.whittle@e-centre.org.uk>]

John, thanks for the comments, but the document isn't yet in public review
and therefore these comments may not reflect the latest version.

ebXML has reasonably well documented procedures in respect to document
review and comment periods, yet it seems that many people are choosing to
ignore these processes. Can we all please respect comment review process and
make everyone's life a little easier.


James Whittle
E Business standards executive

Tel. No. 44 (0)20 7655 9022
Fax No. 44 (0)20 7681 2278


10 Maltravers Street, LONDON, WC2R 3BX.
www Address: www.e-centre.org.uk <http://www.e-centre.org.uk>  
e-mail james.whittle@e-centre.org.uk <mailto:james.whittle@e-centre.org.uk> 


Best business practice in a digital age.

Disclaimer Notice 

The above information is intended only for the person(s) or entity to which
it is addressed, and may contain confidential or privileged material. Any
use (including retransmission or copying) of this information by person(s)
or entity other than the intended recipient is STRICTLY PROHIBITED. If you
are not the intended recipient of this transmission, please would you
contact the sender and delete the material from any computer. The sender is
not responsible for the completeness or accuracy of this communication as it
has been transmitted over a public network. Any views or opinions are solely
those of the author, and do not necessarily represent those of e centreUK.
All third party rights are duly acknowledged. e centreUK  is the trade name
of the Association for Standards and Practices in Electronic Trade - EAN UK
Limited, and is registered in the United Kingdom (Registration Number
1256140). 

© 2000 All Rights Reserved

		-----Original Message-----
		From:	John McClure [mailto:hypergrove@olympus.net]
		Sent:	18 April 2001 22:25
		To:	james.whittle@e-centre.org.uk
		Cc:	ebXML Core
		Subject:	Comments re:ebXML Naming Standards


		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)