RE: [ubl-lcsc] Formulating a response to the UDEF discussions

[Monica Martin <mmartin@certivo.net>]

Suggest an assessment for the following reasons:
1. UDEF is primarily data focused.
2. The CCSD has received comments (and is also actively looking at) the
idea of process focused vs data focused elements (document-centric).
3. Given item 2, the 'view' of the elements and the outcome are
different.

Thank you.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946

Sally, I would very much like to see the UDEF presentation as I was
unable to attend the brief to gain more information.


-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, December 03, 2002 11:32 PM
To: ubl-lcsc@lists.oasis-open.org
Subject: [ubl-lcsc] Formulating a response to the UDEF discussions


At yesterday's meeting I was tasked with drafting a response to Ron 
Shuldt, the chair of the EIA Industry group follow the presentation 
Sally gave on the application of UDEF to the work of UBL.  Here is my 
first draft.  Please add your thoughts to this and send them directly to

me.  I shall edit these into a final version for submission before 
Tuesday 10th Dec.

"The UBL team acknowledge the value of the architectural model described

by UDEF.  The idea of using a hierarchical assembly of objects and their

propoerties which cna be identified by an independant coding system. 
 This formalizes a vocabulary and promotes interoperability by allowing 
differing names/tags to refer to the same semantic component.

In summary the question that rose to the surface was that this 
architecture is somewhat similar to that proposed by ebXML Core 
Components with their naming convention and identification scheme 
equivalent to the Core Component Technical Specification and the CC UID.

 UDEF could  be described  as a type of Core Component Library.  

As UBL is committed to compliance with the ebXML Core Component 
Technical Specification, this could create some issues for us.  For 
example, if the UDEF Object Tree or Property Tree do not align with the 
Core Component Library then we would have potantially duplicate  UDEF 
IDs or no equivalent UDEF ID at all.

We therefore have a few further questions we would like to put to the 
UDEF team:

1.  How do they see the alignment of the UDEF structures with that of 
the CEFACT Core Component work?
2.  How do they see the ongoing governance of the UDEF structures with 
that of the CEFACT Core Component work?
3. What added value does the UDEF ID give other than that already 
provided by the CC UID (ie they both appear to offer interoperability 
mapping)?

We appreciate your advice on thse matters.  As you will appreciate, our 
concern is that we do not embark on parallel developments and thereby 
create even greater fragmentation in this community.
"

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>