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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: RE: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August


Tim, you said "the backward compatibility is only broken at a syntactic level (except in one case of Allowance Charge. CurrencyCode).  we are desperately trying to keep 2.0 as semantically compatible with 1.0 as we can.  that means unless we find 1.0 is broken (as in the case mentioned) we would be very reluctant to change existing structures."
 
I did not notice these multiple structures for party when 1.0 was developed. My preliminary research shows that mostly high-end ERP packages support the use of multiple structures for party. I can name 5 popular ERP software packages in the U.S. for small to medium size (revenues >$10 million < $100 million) companies that only support one structure for party. If you need multiple structures, you must create them yourself, and, they can only be restrictions of the base party.  There are 3 well known accounting packages for companies with revenues of less than $10 million that include modules for sales and purchasing that do not support any changes if you need to define or use multiple structures for party.  Buyer and Seller are universally required for all businesses of all sizes that are involved in commerce and trade. 
 
I agree we need to meet the needs of the existing structures defined in 1.0. I think we also need to find a way to do it that supports the widest possible user community.  The number of 1.0 implementations is low because the standard is in its infancy. Now is the time to recognize the limitations potential UBL users might have with multiple party structures and change it when the user community is small, not after such a change will impact a much larger user audience because the standard is more mature.   
 
Regards,
Sylvia

From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Wednesday, September 07, 2005 6:00 PM
To: Michael Dill
Cc: ubl@lists.oasis-open.org
Subject: Re: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August

my apologies i thought i had sent this but it got held up in my drafts folder :-[

just so we dont lose track of this, I will reference your email and the original minutes in the minutes of yesterday's call.

Michael Dill wrote:
Tim,
obviously I was not able to describe clear enough, what my concerns are.
1. Here is the clarification for point b)
Tim minuted, that there are some concerns about the definition. In case, I
said this, then I apologize: I meant the structure mismatch between the
three existing parties. He argued, and I do not agree, that not to change
this is necessary to maintain compatibility. When it became clear that there
will be no minor version 1.1 but a major version 2.0, a number of backward
compatibility was broken anyway.
the backward compatibility is only broken at a syntactic level (except in one case of Allowance Charge. CurrencyCode).  we are desperately trying to keep 2.0 as semantically compatible with 1.0 as we can.  that means unless we find 1.0 is broken (as in the case mentioned) we would be very reluctant to change existing structures.
If different from Party. Details, then Seller and Buyer should be qualified
from the generic Party. Details. This would be a semantic CCTS restriction
and technically an extension. It could also be, but this is a different path
and not what I mentioned, a subset mechanism.
  
sorry, Sue suggested that we should always use restrictive subsets and I thought you agreed with her.  i now realise your point was different
In cases Seller and Buyer are not different from Party. Details, they should
wherever possible just be defined by an association. Just, if the generic
party is not sufficient a qualified ABIE Seller_ Party. Details should be
allowed to define. Thus a conceptual decision will depend on concrete user
requirements. AND: the necessary decision will become part of a taxonomy how
to describe a number of typical modelling problems.

But, currently, even seller/buyer do not have the same structure.
  
they do not have the same structure because they are used for different purposes and required different pieces of information.  
My concern is, that this mismatch will be a reason to have 30-100 different
structures for parties. Second, and please remember later, that IMO neither
big corporates nor ERP vendors nor central EDI departments will be satisfied
with such a solution. They rather need a generic party in the documents.
  
there is a generic "party" and all re-uses (scuh as Buyer and Seller) use this common structure.  So if application vendors write a function to deal with UBL Party it will handle this common structure.  In addition when they want to process a Buyer Party (or a Seller Party) they will need functionality that deals with the specific requirements of parties in those roles.  I see this a reasonable and logical.

surely it comes down to the fact that when we have additional requirements for specific roles we must have the additional information components that support these requirements.  Currently UBL both conceptually supports the idea of  extension - i thought you would appreciate that.

in our existing models it is not semantic restriction and physical extension.  it is semantic extension and physical re-use.  i see no reason why we should change this.
2. Here the clarification for point 3
The sentence "Michael raised a concern about the decision to adopt ATG2
Unqualified data types meant the modeling of these was outside UBL's
control." is not completely correct. I'm not complaining the decision. I
said, that UBL has to be aware, what it means to use the ATG2 unqualified DT
- for code lists, for further qualification, for code list mechanism - and
that this needs to communicated to users and developers.
Tim argued that with the ATG2 uDT decision, "We now considered our models
stopped at that level." I feel, that in respect of the code list issue and
the qualified DT, this low level is already under discussion.
further apologies, the language could have been better phrased.  it should have read...
"Michael raised a concern THAT the decision to adopt ATG2 Unqualified data types meant the modeling of these was outside UBL's control." 
and as you may have also realized the question of dealing with qualified/specialized data types is still open and being discussed.


best regards,
Michael

-----Ursprungliche Nachricht-----
Von: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Gesendet: Mittwoch, 31. August 2005 14:36
An: ubl@lists.oasis-open.org
Betreff: [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August


Attendees:

Mikkel Brun
Sue Probert
Michael Dill
Peter Borresen
Tim McGrath

1. STANDING ITEMS
 Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm)
Sue:
TBG 17 will meet October 31 - November 4th in Copenhagen and also February
13 to Febraury 17th 2006 in Washington
ATG2 will meet sometime in January 2006 in Australia TMG will also meet
sometime in January 2006 in Australia

 Liaison reports
Noted that the TaxXML position paper was distributed

 Subcommittee reports (including the new Procurement and Transportation
SCs)
Procurement SC will try and complete the model loading into EDIFIX this week
(we think we are 1 week behind the schedule) Transportation SC are working
on merging the two models and removing unnecessary structures from the DTTN
model.

 Team reports
Catalogue team will report weekly on progress

 Review of Asia/Pacific and Atlantic TC minutes No comment

2. CONTENT WORK
* Document Models
status
Peter B has completed and distributed the draft 2.0 extended procurement
models Sylvia is loading them into EDIFIX and will instruct Betty on how to
do maintenance Michael raised some concerns about the content of the
procurement models:
a. how will we deal with "standalone" BBIEs (those not define as re-usable)?
Tim suggested we define these in the Common Basic Component schema but
Michael sought a modelling level solution.  Agreed to continue the
discussion offline until we had defined a position for the TC to consider.
b. How can we have multiple definitions for "Party" (eg BuyerParty,
SellerParty and Party)?
This appears to be a question of whether we want to extend ABIEs when we
re-use them (BuyerParty extends Party) or only allow restriction (Party must
contain all BBIEs and BuyerParty is then a restriction).  Tim suggested it
was acadmeic for UBL 2.0 as we had to support exist extensions.  The
question of whether we should allow only extension, only restriction or both
was unresolved.  Sue noted that CEFACT have adopted a "only restriction"
approach to their models.
c. Michael made a point that the GS1 catalogue/pricelist models were worthy
of consideration.
Tim noted that a representative from GS1 had participated in the Copenhagen
workshop and contributed many useful ideas.  We had to adapt these to fit in
with UBL 1.0 (and now 2.0) models as well.

schedule
We will try and gain back some slippage in the schema generation stage as
initial tests appear promising.

3. NDR WORK
NDR issues for review in tomorrow's meetings.
* code lists
It was noted that any comments on the new NDR document are due now.
Michael raised a concern about the decision to adopt ATG2 Unqualified data
types meant the modeling of these was outside UBL's control.  He felt this
meant that other implementations of CCTS may not be interoperble becaseu UBL
releied on schema level compatibility rather than conceptual level.
Tim suggested that we had delegated low grained models (like Date, Time,
Code, etc..) as data types to CEFACT becasue we hoped every XML
implementation of CCTS would use the same schemas.  We now considered our
models stopped at that level.

4. Other items
none

--
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
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E
-22FF8CA5641F&ttype=2&tid=10476




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
  

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
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
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476



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