RE: re discussion topics

[Murray Maloney <murray@muzmo.com>]

Please see my reply below. I am afraid that David's attempt
to clarify has failed to achieve its goal. 

For the record, I am not confused on this issue. However, I think
that the arguments presented below may be confusing to those who
have not thought them through. 


At 12:25 AM 5/28/00 -0400, David RR Webber wrote:
>Murray,
>
>Below is the clarification you seek on this issue.  It has been
>mis-represented and hence your, and others confusion.
>
>The issue is strongly related to the EDI experience over the
>last twenty years and is a real need.
>
>Anyway - whether this belongs in the RegRep (my preference) or
>Architecture is moot.  I'd suggest a line item to the effect in 
>the Architecture - with a note that the full discussion and implementation
>relates to RegRep.
>
>The need is clear - but it is NOT an issue of meaningful names v neutral
>codes - the issue is that we need BOTH, and that they should be linked
>via context, usage and core component meanings, as outlined below.
>
>Hopefully Duane can get some concensus wording on this now and
>we can move rapidly on to other matters.
>
>Thanks,  DW.
>
>p.s.: Why would CommerceOne, et al need meaningful names? - surely
>          the business need is to obfuscate everything as much as possible
>          so that only vendor products will work?  OK - this violates the 
>          prime-directive so Klaus will chew off exposed body parts if we
>          even think that!  Enjoy, DW.

Hmmm. I don't know whether to take this comment as a serious one or not.
For the record, I believe that Commerce One has previously stated that
it is committed to standards-based, interoperable e-commerce. I don't 
think that suggestions to the contrary are helpful.

>=============================================================
>Message text written by Murray Maloney
>>Seriously, the architecture document should remain silent on this issue.
>
>The shape of names is best left to the Core Components group,
>as it has no impact on the functioning of the Registry/Repository,
>as you have rightly pointed out in the past. Representatives for
>Commerce One, General Motors, Muzmo, Sun, and Commerce Net have 
>already indicated their preference for meaninglful names, as has 
>the Core Components group -- and the recommendations of eCo Project.
>
>Regards,
>
>Murray<
>
>>>>>>>>>>>>>>> Cross post from Reg-rep. >>>>>>>>>>>>>>>>> 
>Jon,
>
>Somewhere in between a few too many Belgium Leffe beers in
>Brussels this whole message got totally twisted around and
>screwed up.  Some major clarifications and corrections are needed.
>
>Hopefully I can clarify all this new.  Here are the facts:
>
>1) Bizcodes are explicitly designed to let end users name/label
>     business entities ANYTHING they like - therefore they are
>     quintessentially mnemonic enabling in nature.

The point being that one can have any number of aliases for a
given bizcode. Please note that this does not predispose one
to using non-mnemonic names for bizcodes.
>
>2) From 1) it follows this is an instant Tower of Babel, and this is
>     the historical problem EDI has faced. To solve it EDI did
>     folding of multiple definitions into single business elements.  Now
>     you have to know CONTEXT in order to deduce meaning and
>     usage.  This as EDI discovered is both expensive to maintain
>     and difficult to use (i.e. need expensive consultant to map your
>     local usage to the 'standard' usage.  Ken Steel coined the
>     term 'dispersed semantics' and designed a repository system
>     to solve this.  Unfortunately while Ken's solution is part of the
>     answer its' not all of it, and in fact using XML to its fullest
>     potential is necessary - to couple meaning, context, and 
>     process into a repository reference and retrieval system.
>
>     Worse - people spend years arguing over names and 
>      mnenonics exactly because they see they have implicit
>     meanings, and they want to avoid two names meaning
>     different things colliding out of context.

Sorry. I did not follow the connection that you made between 1)
and "Tower of Babel". The remainder of this part of the argument
was rendered inoperable.

>
>3) Historical backdrop - DOI - this is an attempt to provide 
>    globally addressable labelling for HTML content - see
>    http://www.doi.org

Pointing out the existence of an organization that agrees with 
your POV is not a useable argument.
>
>4) OK - now we begin to see the premise behind Bizcodes, but
>     there's more.  Let's examine current W3C Schema syntax.
>     We see overhead, tons of it.  Instead of a simple 
>     <!ELEMENT personsname (#PCDATA) >  
>     we have potentially lines and lines of syntax to specify all
>     kinds of properties and behaviours.

You suggest that we examine W3C Schema syntax, and then you use
XML DTD syntax as an example, pointing out that the expression
of properties and behaviours may occupy many lines. Again, your 
argument fails.
>
>     Now 4GL vendors have seen this all before.  The problem is
>     simple.  What if I want to make 'personsname' 55 bytes long
>     now instead of 50 bytes?   Ooops, I have to track down all
>     those schemas everywhere that have hardcoded definitions
>     wired into them.   Therefore - we need to DECOUPLE the 
>     definition of the actual entity from its use in a schema.  No
>     surprises here.

Actually, your assertion here is invalid and false. With Schemas,
one can simply change the 'type' from which 'personname' is derived
and every derived type/element changes accordingly. Anyway, this point
is misleading because the truth value is the same whether you use
mnemonic names or non-mnemonic names.
>
>5) Human usability quotient:  humans remember things based
>     on relevance to their own domain, and that the items are
>     intuitive and simple.  So as Jon noted we want things in
>     context, with nice meaningful names.  This is EXACTLY the
>     system that Bizcodes is designed to empower.  Now - back
>     to Bizcodes again.  I give you the English dictionary and
>     ask "give me a word that means 'complicated'".  You offer me
>     50 different words, and some generic ones like '#$%@ed up'.
>     Which do I choose?  Here's where we need to know context.
>     The XML Topic Map work here is vital.  Coupled this to a 
>     Repository - now the repository is NOT a jumble of words in
>     alphabetic order - but instead words based on context of use
>     and ordered and arranged accordingly.   Now we can use our
>     Bizcodes.  For each domain - I want to know what set that label
>     belongs to.   If you tell me it is 'stockMaturityDate' I have some
>     clues.  But is it wine, cheese, beer, or mutual funds we are talking
>     about?  If I expose the Bizcode as MFB01001 the MFB tells me
>     it is a mutual fund and the 01001 references its definition.
>
>    So I would expect MFB01002 to be related, and so on.   Notice
>    also that if 6 months from now someone decides stockMaturityDate
>     really is too unclear, and that this really is assetMaturityDate, how
>     simple this becomes to re-map - leave the Bizcode as MFB01001
>     and simple change the human readable label.

This argument is interesting. What you are pointing out is that 
people have the potential to mess things up. Yep, that is true.
However, I note that you say 'MFB tells me it is a mutual fund'.
Whereas, I think, you are also suggesting that it is a bad idea 
to use MFB:stockMaturityDate and MFB:assetMaturityDate thusly:

	<element name="stockMaturityDate" type="MFB:MaturityDate"/>
	<element name="assetMaturityDate" type="MFB:MaturityDate"/>

>
>6) Assigning, managing and utilizing Bizcodes.   Industry groups,
>     standards associations and large corporates can develop
>     Bizcode based definitions - just like they do today with barcodes.
>     You don;t go into a store and ask for a '4520-1200-79001'.  But
>      every computer system that touches it thinks it is!  Notice the
>      packaging can change, the size, weight price, et al.  That is the
>     power of a neutral labelling scheme.   Every Bizcode prefixed 
>     with UCC tells me it is the grocery industry domain, and so on.
>
>      We picked 3 bytes alpha and 5 numeric as a manable limit,
>      and also because 8 bytes seems a good pointer length 
>      for legacy systems and the right order of combinations.
>      Notice in the UCC case there are about 7 million barcodes, 
>      but that about 3,500 Bizcodes are needed to describe all
>      the business attributes of those 7 million (weight, colour, size,
>      price, etc) because they are re-usable.
>
>      Notice you can also assign Bizcodes in a logical way 
>      (UNSPSC codes is an example - but not one I'm wildly in love
>        with - too many #'s - not enough alphas!), and this is in part
>        what Jon is after - don't give me a random string - give me
>       something a warehouse quartermaster will love to classify
>       with.... 'all those racks over there have got 10-93's on them....'.
>
>       The more you do this however - the more expensive the
>       codes themselves become to assign, maintain and 
>       validate.  This is why the barcode system of simple
>       sequential number is the simplest.  If people want to add
>       implied meaning - then they have to accept that cost
>       and overhead themselves - see http://www.udef.org

Clearly, it should be possible to employ coded names. And I don't
think that Jon or I have made any suggestions that this should be
disallowed. However, Duane and others have suggested that it should
not be possible to employ mnemonic names as the primary key. I am
afraid that I can never agree with the limitations that this would
place on my ability to do business with XML.
>
>7)  Now we come back to the Schema syntax burden.  What if
>      only line of the schema syntax was needed to reference
>      each element?  And what if that line always had the same 
>      format?  And what if the line was parameterized by namespace?
>      Wow!  We have something which is simple, consist, and
>       predictable.  That is how Bizcodes work.
>
>       There's lots of ways of doing this - here's one using simple
>       attribute in a DTD: so back to our ELEMENT definition:
>
>       <!ELEMENT personsname (#PCDATA) >
>       <!ATTLIST personsname
>                              bizcode CDATA #FIXED "UNE03004">
>
Actually, this method relies on techniques that are not supported 
by most XML software. Anyway, this argument cuts both ways -- since
it works equally well if the primary key is mnemonic.

>      Also - when migrating legacy EDI dictionaries we can
>      use automated processes to assign Bizcodes, rather
>      than an expensive manual process being needed.
>       Then there is those lines of COBOL copybooks & 
>      CICS maps to tackle too....

Again, I have not argued that you should be prevented from using
non-mnemonic names.
>
>8)  Repository linkage with Bizcode and Parser.
>
>      Armed with the fact that 'personsname' is UNE03004 
>      I can now query the repository via its API and return 
>      whatever semantic definitions (in XML) that I require.

Again, this argument cuts both ways.
>
>      Notice if instead (as some are proposing) I had used
>      the 'personsname' I would have a much tougher time.
>      
>      First 'personsname' may occur in multiple repositories
>      with different meaning, and versions.  UNE030041 tells
>       me that the owner is UNEDIFACT - so I go straight to
>       the right repository, and entry 030041.

This not rocket science. I could just as easily use UNEDIFACT:personName

>
>       Using XLink I can insert selected pieces of the XML
>       definition retrieved from the Repository (Bizcode being
>       an 8 byte label means it is XML ID name compliant) 
>       straight into the DOM where application software can then
>       use it.  This then dovetails beautifully into what ebXML core 
>       components are looking to allow software to do.

There is no 8-byte limitation in XML. Please do not try to argue
for that again. The rest of your argument cuts both ways.
>
>In conclusion, please see http://www.bizcodes.org for tons
>of related materials and more details.   

In conclusion, I am afraid that your arguments are not convincing 
in the least. It would help if your arguments were direct and to
the point. Any argument which is valid for both sides of the debate
unnecesarily obfuscates the issue.

I will reiterate, there has been no argument presented so far
that inclines toward the use of non-mneomonic names as the 
primary key.