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

[Michael Adcock <Michael.Adcock@apacs.org.uk>]

Surely we have the solution to this in the 'enveloping' concept that we
employ by having aggregates in the CC Tech Spec, and that we use to good
effect in the UBL work done so far. 

Anyone encountering an aggregate in a data stream has three choices,
(1) go into it and process its detail because they need to get at the
information contained, (2) step over it and ignore it because the
information is not relevant to the processes they have to carry out, or
(3) pass the information untouched down the processing chain because
they know someone else further down the transaction processing chain
does need it. Only in situation (1) do they have to understand its
content, which they will, because they need it for their own business
processes.

We have precisely this situation in UN/EDIFACT Finance messages, where
the remittance information is a 'black box' that is simply passed
through the banking transaction chain, because it is created by the
Payor to tell the Payee what the payment is for. Banks do not look into
the black box!



Mike Adcock
Standards & Security Unit
APACS - Association for Payment Clearing Services
Mercury House, Triton Court
14 Finsbury Square
London EC2A 1LQ
Tel: +44 (0) 20 7711 6318
Fax: +44 (0) 20 7711 6299
e-mail: michael.adcock@apacs.org.uk

>>> Tim McGrath <tmcgrath@portcomm.com.au> 30/04/02 04:19:23 >>>
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
>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 




**********************************************************************
The opinions expressed are those of the individual and not the company.
  Internet communications are not secure and therefore APACS does not  
     accept legal responsibility for the contents of this message.
  If the reader of this message is not the intended recipient, or the
employee responsible for delivering this communication to the intended
recipient, you are hereby notified that any disclosure, distribution or
   copying of this communication is strictly prohibited.  If you have
 received this communication in error, please notify us immediately by
          telephone to arrange for its return.  Thank you.
**********************************************************************