OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: ebxml identifiers


[on behalf of Jon Bosak, writing from an address he's not subscribed from]

[I would really like to eliminate cross-posting between ebxml and regrep
lists; how do the others subscribed to regrep feel?]

Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by oasis.oasis-open.org (8.8.8/8.8.8) with ESMTP id RAA17528;
	Mon, 22 May 2000 17:54:24 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23341;
	Mon, 22 May 2000 15:54:23 -0600 (MDT)
Received: from boethius.eng.sun.com (boethius.Eng.Sun.COM [129.146.83.127])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09892;
	Mon, 22 May 2000 14:54:04 -0700 (PDT)
Received: (from bosak@localhost)
	by boethius.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA06642;
	Mon, 22 May 2000 14:54:03 -0700 (PDT)
Date: Mon, 22 May 2000 14:54:03 -0700 (PDT)
From: Jon Bosak <bosak@boethius.eng.sun.com>
Message-Id: <200005222154.OAA06642@boethius.eng.sun.com>
To: regrep@lists.oasis-open.org
CC: ebxml-regrep@lists.oasis-open.org
In-reply-to: <NDBBIADIILMOHKHOHEPIEEILCHAA.duane@xmlglobal.com>
Subject: Re: SubmissionPackage DTD

[duane@xmlglobal.com:]

| It has been suggested that we use a unique ID which is
| semantically meaningful to at least one person on the planet.  The
| logic there is while no one can define a key which is universally
| acceptable but at least some will be able to make use of it.

I am among those holding the opinion that labels meaningful to
someone are better than labels meaningful to no one.  The
utilitarian calculus on this is pretty simple; if U is the utility
to an individual of being able to use a mnemonically significant
set of terms and N is the number of people for whom a set of terms
in mnemonically significant, then

   U * N > U * 0

for any N greater than zero.

| <IMHO> this is a *really* bad idea.  First off, the political
| upheavel of EDI vs. other standards competing for defining this
| semantically meaningful component will stall all future work.

The assumption here is that the use of *any* meaningful labels
would entail "the political upheaval of EDI vs. other standards".
I'm not seeing any reasoning here to establish that the one thing
would follow from the other.

| Secondly, the unique key is for a Machine to find only, not a
| human.

I see no support for this assertion.  On general principles I find
highly doubtful the proposition that no human being will find
mnemonic labels useful.  At the very least, we humans engaged in
defining the set of labels will find mnemonic qualities useful.
This is particularly true in the case of names for low-level data
elements.

| Therefore, the machine does not care about semantics on the query
| side, only that it can find the item and the item is unique.

>From this it follows that the machine does not care whether labels
are mnemonic.  Computationally, mnemonics are free.

| Once it has a pointer to the item, the semantics for the calling
| app can be derived by performing a "get" type request on the item
| and examining what it is equivalent to.  I human shouldbe able to
| search on the semantic terms it wants.

Yes, but developers (in particular developers of standards) will
have to work with these codes all the time.

If it doesn't make any difference to the end users and it doesn't
make any difference to the machine, then in my opinion the
position that we use terms that are meaningful to no one when we
could just as easily use terms that are meaningful to many of the
developers just doesn't make sense.

Another argument that some people have advanced for using
meaningless codes is that they are language-neutral.  To me this
is identical to an argument that programming languages should use
arbitrary strings for command keywords.  I don't buy that, either.

Having said that, I would like to venture a modest proposal that
may help to allay the concerns of both those who fear a
terminology struggle between EDI factions as well as those who
seek political correctness in the choice of language.  I suggest
that wherever we need a list of terms in circumstances where the
choice of language is computationally insignificant, we use Latin.
The character set is even smaller than US ASCII; it's as
politically neutral a choice as can be achieved in terms that are
mnemonic to anyone; and if the terms are intelligently selected,
they will be mnemonic to almost everyone actually involved in this
work.

I originally put this proposal forward as a joke, but compared to
the absurd conclusion that the optimum solution is the one that
inconveniences the greatest number of people, it's starting to
look genuinely attractive.

Jon





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC