Subject: RE: re discussion topics
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. ============================================================= 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. 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. 3) Historical backdrop - DOI - this is an attempt to provide globally addressable labelling for HTML content - see http://www.doi.org 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. 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. 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. 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 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"> 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.... 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. 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. 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. In conclusion, please see http://www.bizcodes.org for tons of related materials and more details. Thanks, DW.
eList eXpress LLC