[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Order
A few more thoughts on this 1. when people use UBL they tend to use a subset and in some cases they define this subset in some way or they rely on an existing subset (like OIOUBL or NES UBL) 2. when people define a subset they may have a broad closed group of UBL users in mind, as with NES UBL and for such cases they may tend to use a liberal range of semantic interpretations of the entity definitions 3. when people define a subset they are often deciding cardinalities (whether or not element is optional or mandatory, whether mutiples are allowed or not) beyond those defined in standard UBL (but usually in a way which still conforms to UBL schemas - so an element optional in the standard may be mandatory or forbidden in the subset, etc) 4. when people so restrict the cardinality in the subset they are usually making assumptions about the usage and the semantics of the entities concerned 5. when the usage range is broad, there may be reluctance to pin down those assumptions (for the same reasons as in 2. above) 6. really there may be a clash between 4. and 5. 7. maybe subset definers/specifiers should consider, with future work in mind, provided the resources available allow it, trying to define their assumptions formally for all those entities which are modified in the subset (modified in comparison to the standard UBL schemas) Point 7 is akin to my recent efforts to formally define a calculation model for UBL invoices in relation to tax. It might impact on a subset which restricts for its users the entities involved in tax invoice usage how the totals are calculated, eg if LineExtensionAmount has a different calculation model to the TaxExclusiveAmount then it makes sense to ensure that TaxExclusiveAmount is not restricted out of the subset whereas if they are the same (as could be implied in some interpretations of their UBL definitions) then eliminating one (if it is optional) makes good sense to avoid confusion. It depends on the interpretation of the semantics and the resulting calculation model how you define a subset. I hope that the same use of test assertions I have previously suggested for the calculation model might help to formally define the asuumptions made about the semantics and any relevant calculation model. It may allow formal definitions of the subset cardinality restrictions too. If conformance to UBL is not the objective then, where there is customising which goes beyond using the schema languages of DSDL, etc, maybe the test assertions methodology can be used for this too. I hope so. I guess I'm hoping the same formal assertion methodology can support all these many aspects of document conformance profile definition and customisation. Of course all this means a lot of effort in defining profiles - the specs being supported by formal test assertions which in turn can in many cases support test execution in a validation engine and in other cases provide a set of clear, unambigious semantics and usage definitions to help the implementer all written in the same test assertion format. ref: http://lists.oasis-open.org/archives/ubl-dev/200907/msg00000.html Best regards Steve Stephen D Green Document Engineering Services Ltd 2009/7/4 Stephen Green <stephengreenubl@gmail.com>: > I'm not all that convinced that it matters though. > The intention, as far as I'm concerned, was not > to dictate how these IDs are used: If someone > finds value in using something called > CustomerAssignedID for a particular purpose > then as long as all parties concerned agree to > it, it is up to them. There would be a best > practise to consider any future readers of the > documents but I'm not sure the semantics of > UBL should enforce this because we know we > cannot consider all possible and actual use > cases and we want to leave room for those we > have not considered. If people want to narrow > down the semantics for a subset of all possible > use cases and they have established those use > cases then they can write a conformance > profile which covers the semantic aspects of use. > > Stephen D Green > > > > > 2009/7/4 Roberto Cisternino <roberto@javest.com>: >> Many thanks Stephen for pointing this out. >> >> We should revise some Annotations into UBL 2.x to provide some samples and >> suggestions like those available for the use of Incoterms 2000, so on. >> >> Sometime is difficult to make the right interpretation of data. >> >> Thanks! >> >> Roberto >> >>> Pitching in with my view too, I think >>> >>> >>>> <cac:BuyerCustomerParty> >>>> <cac:Party> >>>> <cac:PartyIdentification> >>>> <cbc:ID >>>> schemeURI="http://www.dnb.com/US/duns_update/";>12345</cbc:ID> >>>> </cac:PartyIdentification> >>>> >>> >>> is the right way to handle the DUNS number. >>> >>> I brought to UBL the CustomerAssignedID and did not >>> intend it be used for DUNS or EAN numbers, etc. >>> Customers and Suppliers sometimes assign to >>> eachother an ID which does not exist outside of >>> their trading relationship. This is the place for such >>> IDs, not for IDs assigned by independant bodies >>> like DUNS. >>> >>> Sorry Roberto :-) Thanks Ken >>> >>> Best >>> >>> Steve >>> >>> Stephen D Green >>> Document Engineering Services >>> >>> >>> >>> 2009/7/3 G. Ken Holman <gkholman@cranesoftwrights.com>: >>>> At 2009-07-02 09:32 -0400, Marzka, Jeremy wrote: >>>>> >>>>> I am currently working on mapping trading partner order requests to a >>>>> UBL >>>>> order and have a couple questions. >>>> >>>> All questions are very welcome, Jeremy. I hope UBL-Dev participants do >>>> not >>>> hold back. >>>> >>>> Different volunteers have different perspectives on UBL and can help in >>>> different areas. I cannot help you much on the business side, but I >>>> have a >>>> comment below regarding identifiers. >>>> >>>>> Where would you recommend that I map the following? >>>>> 1. FOB code and description (FOB Origin, FOB Destination...) >>>>> 2. Ship Method (Air Freight, Motor Freight, Customer Pickup...) >>>>> 3. Carrier Code (FedEx Priority, UPS 3-Day, UPS Ground...) >>>>> >>>>> I also am confused by the different parties. Am I correct in assuming >>>>> that >>>>> I can map the following? >>>>> >>>>> Sold To -> Buyer Customer Party >>>>> Bill To -> Accounting Customer Party >>>>> Ship To -> Delivery >>>> >>>> I see that Roberto has answered the above questions regarding business >>>> entities. >>>> >>>>> Our trading partners pass us a DUNS number (Dun & Bradstreet) that >>>>> uniquely identifies them. Where should I map this? To the Buyer >>>>> Customer >>>>> Party -> Party > Party Identification > ID? >>>> >>>> Yes, I would have used that, and I see Roberto endorses it as a general >>>> method of identification. >>>> >>>> But I wanted to say it would help to identify the identification method >>>> since many identification methods might produce similar identifiers. I >>>> think perhaps something like the following would be unambiguous and >>>> acceptable: >>>> >>>> <cac:BusyerCustomerParty> >>>> <cac:Party> >>>> <cac:PartyIdentification> >>>> <cbc:ID >>>> schemeURI="http://www.dnb.com/US/duns_update/";>12345</cbc:ID> >>>> </cac:PartyIdentification> >>>> ... >>>> >>>>> Sorry if these questions are unclear I am relatively new to this. >>>> >>>> Thank you for asking them! >>>> >>>> . . . . . . . . . . . Ken >>>> >>>> >>>> -- >>>> Possible July/August XSLT/XQuery/XSL-FO training in Oakland/CA/USA >>>> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ >>>> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video >>>> Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 >>>> Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 >>>> G. Ken Holman mailto:gkholman@CraneSoftwrights.com >>>> Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/u/bc >>>> Legal business disclaimers: http://www.CraneSoftwrights.com/legal >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>> >>> >> >> >> -- >> * JAVEST by Roberto Cisternino >> * >> * Document Engineering Services Ltd. - Alliance Member >> * UBL Italian Localization SubCommittee (ITLSC), co-Chair >> * UBL Online Community editorial board member (ubl.xml.org) >> * Italian UBL Advisor >> >> Roberto Cisternino >> >> mobile: +39 328 2148123 >> skype: roberto.cisternino.ubl-itlsc >> >> [UBL Technical Committee] >> http://www.oasis-open.org/committees/ubl >> >> [UBL Online Community] >> http://ubl.xml.org >> >> [UBL International Conferences] >> http://www.ublconference.org >> >> [UBL Italian Localization Subcommittee] >> http://www.oasis-open.org/committees/ubl-itlsc >> >> [Iniziativa divulgativa UBL Italia] >> http://www.ubl-italia.org >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]