[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] Tag structure discussion kick-off
Hello Folks, After listening in on my first teleconference I would like to add my opinion to the discussion on UIDs and highly structured names. I have listed UIDs as my first priority as I feel that this is more important than having highly structured names (which I feel are necessary as well). I have had a number of years experience in inventory management at the retail level and we have found that a Universal Identifier such as a barcode to be invaluable reference. One only worries about the bar code when beginning to construct a stock management system. If one is not present a number is invented for the product so that it can conform with the system. UIDs are a way of life in the business world and we would be remiss in not including them, especially if one of our aims is to be ebXML compliant. As with ebXML, these numbers should not have any semantic meaning what so ever. It is a similar practice that I have used in the construction of stock management systems in the retail and hospitality sectors. When I find that this methodology has not been used, the item "numbers" are confusing and often the system designers run out of numbers, thus breaking their methodology and thus meaning. While UDEF UIDs seem to be logical and are designed to be unique to someone familiar with UDEF, they would appear to a lay person as confusing and present a new "language" to learn. This may present a barrier to a person or entity taking up UBL. Secondly giving the UIDs a semantic meaning would not be compliant with ebXML. This then leads us to the issue of structured names. I feel the most important issue is to present UBL names, which are the most visible part of UBL, in a highly structured manner in order to have as much semantic clarity as possible. This makes the semantic meaning of the names very precise and understandable to the users of UBL. This also has a parallel to my experience in naming stock items. In practice we follow the ObjectClassPropertyTermRepresentationTerm methodology as ISO 11179-5 and ebXML uses. So we are presented with the option of using a naming convention and methodology that is clear and represented by an international standard for UBL. The only draw back, as presented by others, is the possible length of the names and the computer memory "space" the names may use. As we are in an era that no longer concerns itself with every bit and byte and knowing the future will be less concerned, I feel we should err on the side of semantic clarity and adopt the ISO 11179-5 methodology. Regards, John C Dumay -----Original Message----- From: Eve L. Maler [mailto:eve.maler@sun.com] Sent: Thursday, 13 December 2001 8:06 AM To: ubl-ndrsc@lists.oasis-open.org Subject: [ubl-ndrsc] Tag structure discussion kickoff From the latest minutes: * * * Outstanding issues: - Do we use highly structured names (option 1) or slightly structured names (option 2)? - Do we use fully qualified structured names (option 1a) or abbreviated structured names (option 1b)? How much abbreviation do we want to allow? - Do we use ebXML/11179-style names (option 1E) or UDEF-style names (option 1U)? - Do we add attributes to UBL elements that link them to the UDEF structured UIDs? ACTION: Everybody to discuss this on the list! * * * Okay folks, have at it! I will be on vacation from tomorrow through next Tuesday, so won't be able to participate during that time. Here are my thoughts on the matter, as unformed as they may be: - I think regularity is important, and can't see much "intuition-affecting" difference between Mark's xCBL example and his modified option #1 version (which uses 1b, by the way). So I'm in favor of option 1. - I prefer option 1b, so that we give reusability some amount of importance. I think we should try to come up with an algorithm (not a heuristic), if we can, to ensure that our regularity stays regular. - I prefer option 1E, so that we can more easily align with semantics that we know are important to us and so that the Library Content SC can continue to work in the effective way that they've been using so far (working off of CC semantics). I see nothing inherently wrong in the UDEF semantic trees (though I don't know them very well yet), but do have some questions about the object words that are aligned with context drivers -- how would that work against the context methodology that needs to be developed? It sounds a bit weird to be baking context into base UBL. - I don't, in principle, have a problem with adding UDEF UIDs to our leaf elements. I see this as very much an adjunct, however, and it could possibly be done at a later stage. Perhaps because I'm not entirely familiar with the usage/processing situations envisaged for these "hub" semantic sets, I have some doubts about how helpful it really is to link up to a standard semantic when the internal structure of the so-marked element can possibly be arbitrarily different from any other such element on the planet. (Or maybe this is solved only by linking from leaf nodes?) Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC