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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: RE: [ubl-ndrsc] Tag structure discussion



Mark,

I guess the only value that I bring to the table is naivety and I'm not
afraid of using it.

This notion of a BIE catalog (which is still a stranger in the UN/CEFACT
architecture) introduces a 2nd UID.  This 2nd UID is the one that I believe
that UDEF (or some other numbering taxonomy) may be appropriate, because we
now apply a context to the application or aggregate of core components.
You and I  have talked briefly about the concept of using the UID of core
components to construct a meaningful UID for BIE's, but I don't see that
anywhere in the UBL standard.

The analysis of xCBL elements and the determination of "context" as they
apply to UBL is the currently the work of the Library Content SC.  This
focus has shifted a bit over the past several weeks as the tools SC has
emerged (thank you Gunther) and helped us to look at UBL as a schema
instead of a spreadsheet.  However, we still must focus on the analysis of
the context and we still need a way to render in a manner that is obvious
and/or learnable to the outsider.

You and I worked together on the order.summary document.  The same object
classification that we applied to the (library) element names could be
applied to the UID assignment.   The default name *could* be the UDEF name
or it could be something else (I just hope its ebXML compliant).  Yes, the
UID association may be a little more work, and yes, it makes the name a
little less important, but doesn't it add a whole bunch of value when you
consider that the names are going to be a noise factor anyway?

I personally don't believe that the text names assigned by UBL will
override any of the plethora of vocabularies out there ( I used to, by the
way).  However, the UBL UID's have an opportunity to be very significant.

I look forward to the consensus of this committee.

[respectfully shuffling back to my observer chair]

marion


Marion A. Royal
202.208.4643 (Office)
202.302.4634 (Mobile)


                                                                                                                   
                                                                                                                   
                    "CRAWFORD,           To:     ubl-ndrsc@lists.oasis-open.org                                    
                    Mark"                cc:     (bcc: Marion A. Royal/ME/CO/GSA/GOV)                              
                    <MCRAWFORD@lm        Subject:     RE: [ubl-ndrsc] Tag structure discussion                     
                    i.org>                                                                                         
                                                                                                                   
                    12/19/2001                                                                                     
                    06:59 AM                                                                                       
                                                                                                                   
                                                                                                                   






>After all, why are ebXML
> elements given
> unstructured UIDs?

In the ebXML architecture, the work of matching the UID to the tag/core
component/bie occurs in the registry so structure is unimportant.  You will
either know the value of the item you are looking for, or not.  If you have
structured tags, then it is much more likely that you will get a match.  I
don't see how having a structured ID number will in any way ease the lookup
or cross reference.  Just as you must follow the rules for structured tag
(Object Class, Property Term, Representation Term), so you must follow the
rules for developing a structured UID.  In both cases, the ability to
follow the rules is important to arrive at something that can be searched
for.  Neither has an advantage over the other, other than structured tags
carry a semantic value that structured UID's do not and so are more
intuitive and less dependent on a mathematical conversion routine. And
remember, a large part of our audience will be folks that must rely on what
they see to convey semantic clarity.

I wholeheartedly agree that structure of the tag name is important,
especially when we consider that one of the principle aims of UBL is to
develop a standard business XML vocabulary (See Jon's recent presentation
and the prominence this theme plays).  Unstructured, or semi-structured
tags just do not accomplish this goal. However, the argument for structured
ID's just hasn't convinced me they are necessary.  It seems to me it is a
lot of complication that adds an unnecessary layer on top of  the
structured tag name approach.

Mark







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


Powered by eList eXpress LLC