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

[Tim McGrath <tmcgrath@portcomm.com.au>]

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:
> 00cb01c1ef5b$e497f1b0$f66ca8c0@bolero.net">
> 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
> unnecessary.
>
>     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.
>
>      e.g.
>
>                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.
> >
> > --
> > regards
> > 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>
>
> .
>
>     
    
-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142