From: Tim
McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Thu 6/01/2005 6:27 PM
To: Ram Kumar
Cc: jon.bosak@sun.com
Subject: Re:
CIQ V3.0 schemas
as we
discussed, i have tried to map the xAL-3.0.5 schemas to the UBL
1.0
Address BIE. the results are included in the attached
spreadsheet.
WHAT
DOES THE COLOR CODES (YELLOW AND PINK) IN THE SPREADSHEET
REPRESENT?
these represent the concepts of the ebXML Core
Component Technical Specification...
white rows are Basic Business
Information Entities (BBIE or in XML terms these are implemented as the
elements)
pink rows are Aggregate Business Information Entitites (ABIE or
in XML terms these are implemented as complex types)
yellow rows are
Association Business Information Entities (ASBIE or in XML terms these are
nestings of one ABIE within another)
From this it appears that we still have
some issues with naming and
design rules. For example CIQ uses attributes
for business information
entities or core components - UBL only uses
elements.
I AM
NOT CLEAR HERE. CAN YOU EXPLAIN THIS WITH AN EXAMPLE?
FOR
YOUR INFORMATION, IN XAL AND XNL, EVERY ELEMENT USES ATTRIBUTES TO DEFINE
A
CODE
AND CODE TYPE THAT IS USED BY POSTAL AUTHORITIES TO REPRESENT AN
ELEMENT.
WE ALSO
HAVE ATTRIBUTES TO DEFINE THE TYPE OF ELEMENT AND ALSO
TO
DEFINE SEPARATORS SUCH AS "-","/","No.", ETC USED BY ORIGINAL DATA AND WE
CANNOT AFFORD
TO
LOOSE ANY PIECE OF ORIGINAL DATA.
UBL is based on the ebXML CCTS core component
types. So one BBIE can only be one of Amount, Binary Object, Code,
DateTime, Identifier, Indicator, Measure, Numeric, Quantity or Text (as
primary representation terms) or Graphic, Picture, Sound, Video, Date,
Time, Value, Rate, Percent or Name (as secondary representation terms) data
types. Each of these data types is implemented as a simpleType in XSD
and its attributes are given to us by the ebXML Core Component
Technical specification. It means UBL (and any other ebXML CCTS
vocabulary) should only be defining elements and their higher
structures.
In your case we end up having to map UBL elements to xAL
attributes. The actual case in point was the use of
addressDetailsID as an attribute of AddressDetails - whereas in UBL
this is an element called ID within the Address structure.
The
idea used in xAL and xNL of having codes and types for each element is at
odds with the basic concepts of Core Components. in fact, it harks
back to the old ambiguous EDI standards that we have been trying to get away
from. depending on what code types are used the structures could mean
completely different things - this makes interoperability very difficult
even when both parties use xAL or xNL.
My personal opinion is that
the logical extension of this "code plus type" thinking leads us to only
needing one element with two attributes to describe anything in the whole
universe. one to the define the value and the other to explain what it
is. clearly this is not realistic and the correct direction is to be
more explicit about the meaning of elements in their primary definition and
close the opportunity for ambiguity.
Also, there is an obvious difference in the
conceptual models used by
UBL and xAL. For example, can you explain the
criteria for deciding why
BuildingName is at one level and Premise
details at another? or why
there is AddressLines with children of
AddressLine and at another level
there is
FreeTextAddressLine?
YOU ARE
CORRECT. THIS WAS AN OVERSIGHT AS IT IS ONLY A DRAFT
VERSION.
what was the oversight? and what should it have
been? the question is really what analytical methods were applied to
make structural design decisions?
THANKS
FOR POINTING THIS OUT. IF YOU SEE ANY FURTHER ISSUES,
PLEASE
LET US KNOW.
it would help if you have some conceptual model that
describes the
business rules xAL uses.
WE ARE WORKING ON
IT.
IT WILL
BE GREAT IF YOU CAN LOOK INTO THE POSSIBILITY OF USING XNL
SPECS.
THAT
DESCRIBES PARTY NAME.
my concern is that i had thought you were moving the
work of CIQ closer to that of ebXML Core Components and UBL Naming and
Design Rules but if anything this version moves away from these
specifications. i suspect we will have difficulty converging with the
xNL model for Party Names for similar reasons.
I LOOK
FORWARD TO YOUR COMMENTS.
Regards,
Ram
Ram Kumar wrote:
>Dear
Tim,
>
>It was great catching up at the OASIS
Conference
>in Sydney.
>
>As discussed and agreed, please
find enclosed the draft version
>of the schema (xAL-Basic V3.0) that
we have been working
>on for the past couple of months. This schema
uses some of the
>UBL NDR for defining elements and attributes.
Not all UBL NDR
>could be used because CIQ specs. are used for various
applications
>and not just shipping, purchase order, invoicing, etc.
This V3.0
>draft address schema is used by CIQ TC to map the UPU
international
>addresses (about 170+ country addresses have been
mapped so far).
>
>I have also enclosed Party (a person or
organisation)
>Schema (xNL-Basic V3.0) that I want UBL to seriously
consider re-using
>it in the next version. This schema supports about
36+ party name
>formats that exists in 240+
countries.
>
>As suggested by you, it would be great if you can
look into it
>and make recommendations on what has to be done to make
it
>compatible to Core components.
>
>The new schema is a
flat structure compared to the previous one,
>but does not loose the
flexibility offered by the previous one.
>
>I am very keen to
see "strong convergence" between UBL and CIQ work in
>the party name
and address area and other party information specs
>that CIQ TC has
produced (eg. telephone, email addresses,
>other contact details, etc)
in the future. This convergence should
>set an example to other TCs
within OASIS on how the TCs should re-use
>work atleast within OASIS
first.
>
>Looking forward to hearing from
you.
>
>Regards,
>
>Ram
>
>Ram
Kumar
>General Manager
>Software R&D and
Architecture
>MSI BUSINESS SYSTEMS
>Suite 204A, 244 Beecroft
Road
>Epping, NSW 2121, Australia
>Direct: +61-2-9815
0226
>Mobile: +61-412 758 025
>Fax: +61-2-98150200
>URL:
www.msi.com.au
>
>
>
--
regards
tim
mcgrath
phone: +618 93352228
postal: po box 1289
fremantle western australia 6160
DOCUMENT
ENGINEERING: Analyzing and Designing Documents for Business Informatics and
Web Services
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
Also, there is an obvious difference in the
conceptual models used by
UBL and xAL. For example, can you explain the
criteria for deciding why
BuildingName is at one level and Premise
details at another? or why
there is AddressLines with children of
AddressLine and at another level
there is
FreeTextAddressLine?
YOU ARE
CORRECT. THIS WAS AN OVERSIGHT AS IT IS ONLY A DRAFT
VERSION.
THANKS
FOR POINTING THIS OUT. IF YOU SEE ANY FURTHER ISSUES,
PLEASE
LET US KNOW.
it would help if you have some conceptual model that
describes the
business rules xAL uses.
WE ARE WORKING ON
IT.
IT WILL
BE GREAT IF YOU CAN LOOK INTO THE POSSIBILITY OF USING XNL
SPECS.
THAT
DESCRIBES PARTY NAME.
I LOOK
FORWARD TO YOUR COMMENTS.
Regards,
Ram
Ram Kumar wrote:
>Dear
Tim,
>
>It was great catching up at the OASIS
Conference
>in Sydney.
>
>As discussed and agreed, please
find enclosed the draft version
>of the schema (xAL-Basic V3.0) that
we have been working
>on for the past couple of months. This schema
uses some of the
>UBL NDR for defining elements and attributes.
Not all UBL NDR
>could be used because CIQ specs. are used for various
applications
>and not just shipping, purchase order, invoicing, etc.
This V3.0
>draft address schema is used by CIQ TC to map the UPU
international
>addresses (about 170+ country addresses have been
mapped so far).
>
>I have also enclosed Party (a person or
organisation)
>Schema (xNL-Basic V3.0) that I want UBL to seriously
consider re-using
>it in the next version. This schema supports about
36+ party name
>formats that exists in 240+
countries.
>
>As suggested by you, it would be great if you can
look into it
>and make recommendations on what has to be done to make
it
>compatible to Core components.
>
>The new schema is a
flat structure compared to the previous one,
>but does not loose the
flexibility offered by the previous one.
>
>I am very keen to
see "strong convergence" between UBL and CIQ work in
>the party name
and address area and other party information specs
>that CIQ TC has
produced (eg. telephone, email addresses,
>other contact details, etc)
in the future. This convergence should
>set an example to other TCs
within OASIS on how the TCs should re-use
>work atleast within OASIS
first.
>
>Looking forward to hearing from
you.
>
>Regards,
>
>Ram
>
>Ram
Kumar
>General Manager
>Software R&D and
Architecture
>MSI BUSINESS SYSTEMS
>Suite 204A, 244 Beecroft
Road
>Epping, NSW 2121, Australia
>Direct: +61-2-9815
0226
>Mobile: +61-412 758 025
>Fax: +61-2-98150200
>URL:
www.msi.com.au
>
>
>
--
regards
tim
mcgrath
phone: +618 93352228
postal: po box 1289
fremantle western australia 6160
DOCUMENT
ENGINEERING: Analyzing and Designing Documents for Business Informatics and
Web Services
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476