[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
From: Michael Dill [mailto:dill2@gefeg.com]
Sent: Monday, September 12, 2005 5:35 PM
To: ubl@lists.oasis-open.org
Subject: AW: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st AugustTim,I hope that you will be able to explain the opinion to the real world, that there is one party structure in UBL only! I assume that the real world considers most of the role extensions as part of the party. details. But let's see, what will happen.btw: the more I look at the library(ies), the more I feel, it will be at least extremely difficult to maintain, understand and reuse this.regardsMichael-----Ursprüngliche Nachricht-----my point to michael was that UBL 1.0 does not have "multiple structures for party" - we have only one structure for party. when a party plays the role of Seller we have additional properties. But that is not a new definition for party. It is an extension of the existing definition. it seems a logical way to do extensions but i am happy to see an alternative proposal.
Von: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Gesendet: Donnerstag, 8. September 2005 08:42
An: swebb@gefeg.com
Cc: 'Michael Dill'; ubl@lists.oasis-open.org
Betreff: Re: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August
or, are you suggesting that we can only restrict structures (such as ABIEs) and not extend them?
Sylvia Webb wrote:
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,Sylviamy apologies i thought i had sent this but it got held up in my drafts folder :-[
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
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:
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.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.
sorry, Sue suggested that we should always use restrictive subsets and I thought you agreed with her. i now realise your point was differentIf 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.
they do not have the same structure because they are used for different purposes and required different pieces of information.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.
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.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.
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-- 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]