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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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

Subject: Re: [ubl-comment] UBL comments on ebXML Core Components TechnicalSpecification v1.8

I understand your concern and I am not one who believes in the word 'never' - 'to be avoided' is probably more appropriate.

But, to take your case-in-point, what is the alternative to maintaining separate structures? - maintaining lists of 'goods attributes'?

The point is that  for two parties to understand semantics they either agree what to call the thing or they agree to use the same coded reference for the thing.  I also agree the 'description' is not an viable option.  What you have highlighted is that sometimes a party is not too concerned about semantics - just structures/syntax.  They need data exchange but not interoperability.  That is, a carrier is not primarily concerned with the colour of the fabric - just that is must be reported on their documents.  These meta-data codes help that process, but  rely upon an agreed (and maintained) sets of meta-data codes.  So in effect, they trade-off direct data structure maintainance for indirect data code maintainance.  

As you say, sometimes thats an option.  But my guess is that if a carrier (and i know a few of them) could charge different rates for different colour fabrics - then they would want interopeability and build the structures necessary.

Do you think we could say 'not conducive to interoperability' rather than 'never'?  

Philip Goatly wrote:
Tim ,

I believe it is far too doctirnaire to say that codes should not/never
be used for meta-data.

I do however concur that if one is a particular industry - communicating
with another member of that industry- then using codes for meta-data may be

However if a particular party, like a carrier has to deal with many
industries - up to say 20 - then using meta- data to represent 'Product
Attributes' is one way to reduce the plethora of data formats, that the
carrier will have to deal with, unless meta data is used.


If a carrier deals with: Retail for example he will need :
size,color,SKU,Season,washing instructions etc
If he also deals with metals (Aluminium) he will need :
Weight,Volume,Various Analyses and SKU Color etc will be irrelevant.
At the same time he may have to deal with TractorParts,
Automobiles,Coal, Iron,Food, Aircraft parts,Oil etc

Believe me for a carrier many of these pieces of data are
required in separate fields - you can't just have a non-parsable 'Goods
Description' string

If he has to maintain different data strucutres for all these possibilities,
he will curse us or just won't do it.I suspect the latter.

I hear what is being said but I think a total ban is asking for trouble

Cheers, Phil

----- Original Message -----
From: "Tim McGrath" <tmcgrath@portcomm.com.au>
To: <ubl-comment@lists.oasis-open.org>
Sent: Monday, April 29, 2002 7:11 AM
Subject: [ubl-comment] UBL comments on ebXML Core Components Technical
Specification v1.8

In response to the UN/CEFACT's Electronic Business Transition ad-hoc
Working Group's (eBTWG) call for comments on their ebXML Core Components
Technical Specification (see http://www.ebtwg.org/news/040402.html), we
are attempting to prepare a consolidated response from UBL members based
on our recent experiences with implmenting some of the concepts and
rules indentified.

Please find attached the current working draft of this response. If you
would like to contribute or comment on our comments, then please do so
within the next 48 hours using this list. We plan to discuss these
responses at this week's NDR and LC subcommittee meetings. The date for
submission to the eBTWG is Saturday May 4th.

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

This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service.

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


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

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

Powered by eList eXpress LLC