[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [ubl] clarification [ubl] Minutes for Europe/Asia TC meetingWednesday 31st August
Tim, Thanks for the reference. Martin F as always has relevant patterns to share. Judging from the paper, experiances and other semantical techniques it seems relevant to separate information about the role that a legal entity, party plays with respect to a communication/document and its statements. Since role is [0.1] to Party it seems easy to flatten the structure to a gigantic Party stucture if needed. Im currently preparing a small presentation for the week after next, on how the topic: "eat the cake and keep it" where I show, using Role/authorisedRole, +party/business partner, how classification of partner and their roles can be seamlessly integrated with Core Components and classical UML techniques. Ive put some CCL diagrams here and the UML diagrams later, <http://www.toolsmiths.se/company/Services/DomainSpecificModeling/dsm_CCL/dsm_ccl_examples/dsm_ccl_examples.html> thanks /anders Tim McGrath wrote: > I guess we agree to disagree. But if you want some background to > re-use of patterns then you might find Martin Fowler's article listed > below of interest. > > http://martinfowler.com/apsupp/roles.pdf > > Michael Dill wrote: > >> Tim, >> 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. >> regards >> Michael >> >> -----Ursprüngliche Nachricht----- >> 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 >> >> 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. >> >> 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, >>> 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 >>> >>> >>> >> >> -- >> 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 >> >> >> > -- Best Regards /Anders //////////////////////////// / Anders W. Tell / / Financial Toolsmiths AB / / <anderst@toolsmiths.se> / //////////////////////////// ----------------------------------------------------------------------- CONFIDENTIALITY AND DISCLAIMER NOTICE This e-mail in its entirety, including any associated files, are confidential and intended only for the addressee named above. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use of the information contained within this email or attachments is strictly prohibited. The contents should not be disclosed to any other person nor copies taken. Any views or opinions presented are solely those of the sender and do not necessarily represent those of Toolsmiths unless otherwise specifically stated. As internet communications are not secure we do not accept legal responsibility for the contents of this message nor responsibility for any change made to this message after it was sent by the original sender. We advise you to carry out your own virus check before opening any attachment as we cannot accept liability for any indirect or consequential damages sustained as a result of any software viruses. If you have received this email in error, or if you are concerned with the content of this email please notify Toolsmiths by sending e-mail to us at: info@toolsmiths.se. -----------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]