[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Contracts - Simplifying the next version of UBL
Ken, Thanks for the analysis. I was not clear - I was thinking conceptual contract related - not just anything with "contract" in its name. So everything pretty much above Catalogue Line Items falls into that bucket! E.g. signer, tax, organization, dates valid, and on and on. Weird as it may seem - I believe most supply chain systems just want to the see the line items and quantities on hand with general location, packaging and shipment type - and some cursory indication of relative date and supplier / distributor identifiers. All that other stuff (e.g. 90% of the XSD structure) is really tangential to the business purpose - notifying people what is available. If we create the notion of Contract as a vehicle for exchanging all the regulatory and ownership and tax and shipment details - then it moves out of the schema fully most of what I'm seeing right now is just message bloat. I suspect the same principles can apply to other schemas too. E.g. there is static information that relates to the contract and overall agreement between parties - that really does not need to be sent in EVERY message that relates to it - instead a simple reference ID suffices. I also see this is more in line with modern SOA principles and BPM - where you establish the terms of interchange - contractual relations - then begin the business exchanges. The ebXML CPA is of course the operational criteria. But the UBL model inherited from EDI really did not address CONTRACT as an entity - because EDI did all that stuff by FAX and hand prior to - and it was assumed. Now appears UBL has inserted the contract details into the EDI transaction model - for convenience - so as not to have to create new transactions. But really - the optimal way is to create a BPM for contractual setup - and have that fully supported by transactions - and then optimize the UBL accordingly. We really don't need folks have to figure this out for themselves - when UBL is supposed to be "ready to go" out the box. Having to wade thru 11,150 elements yourself is probably way more than any LEGO kit and most jigsaw puzzles that have ever been sold, eh? Whereas the order with its millions is more like building a space shuttle from scratch yourself. Don't think eBay is selling one of those - but I'm sure if they did Richard Brandson would buy it... Hardly something for your corner grocery store or kindergarten provider!?! Thanks, DW -------- Original Message -------- Subject: Re: [ubl-dev] Contracts - Simplifying the next version of UBL From: "G. Ken Holman" <gkholman@CraneSoftwrights.com> Date: Fri, May 02, 2008 10:03 am To: ubl-dev@lists.oasis-open.org At 2008-05-02 06:00 -0700, David RR Webber \(XML\) wrote: >In looking at the Catalogue XSD - when you generate a complete XML >instance per the XSD schema - you get a 2.1MB transaction!!! My analysis shows Catalog has 11,150 different elements in context and 28,965 attributes for those elements, not counting recursion. This is actually quite small compared to, say, the Order which has 830,338 different elements in context and 2,171,455 attributes, not counting recursion. I get these numbers from the latest versions of the XPath files: http://docs.oasis-open.org/ubl/submissions/XPath-files/ >Clearly - noone is sending 2.1MB to describe one catalogue item >(least I hope not!). Yes, from day 1 we were not expecting people to use *all* of UBL in a single instance. The library contains what people conceivably might need ... they can then customize it to whatever they do need in a community's customization. >So - when I look at the content - most all of it relates to static >CONTRACT related information - that really could be placed into a >separate and new UBL transaction - and then simply referenced by an ID. Actually, I see only 37 elements related to a contract, and these are all through <cac:ReferencedContract> which points to the external contract through <cac:ContractDocumentReference>. I do see many elements related to <cac:ContractorCustomerParty>, which shows up both at a document level and at a line level, but those are big only because they include <cac:Party> which is big. >This would introduce a new process flow into the information >equation - but seems entirely logical. So if I need to know the >contract conditions relating to an item - I can request that. > >The design decision to burden the catalogue exchange with Contract >related content (which makes up 90%) Again, I'm missing this ... as far as I can tell, from the XPath files cited above, these are the *only* elements related to the contract in the entire catalogue instance: 37 0..n /ct:Catalogue/cac:ReferencedContract/ 38 0..1 /ct:Catalogue/cac:ReferencedContract/cbc:ID 39 0..1 /ct:Catalogue/cac:ReferencedContract/cbc:IssueDate 40 0..1 /ct:Catalogue/cac:ReferencedContract/cbc:IssueTime 41 0..1 /ct:Catalogue/cac:ReferencedContract/cbc:ContractTypeCode 42 0..1 /ct:Catalogue/cac:ReferencedContract/cbc:ContractType 43 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/ 44 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:StartDate 45 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:StartTime 46 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:EndDate 47 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:EndTime 48 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:DurationMeasure 49 0..n /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:DescriptionCode 50 0..n /ct:Catalogue/cac:ReferencedContract/cac:ValidityPeriod/cbc:Description 51 0..n /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/ 52 1..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:ID 53 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:CopyIndicator 54 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:UUID 55 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:IssueDate 56 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:DocumentTypeCode 57 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:DocumentType 58 0..n /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cbc:XPath 59 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/ 60 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject 61 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/cac:ExternalReference/ 62 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/cac:ExternalReference/cbc:URI 63 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/cac:ExternalReference/cbc:DocumentHash 64 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/cac:ExternalReference/cbc:ExpiryDate 65 0..1 /ct:Catalogue/cac:ReferencedContract/cac:ContractDocumentReference/cac:Attachment/cac:ExternalReference/cbc:ExpiryTime I would think the existing approach addresses your concerns. >- seems counter intuitive - when that could be sent separately on >request once - instead of everytime the catalogue entry is updated. > >Not only that - but I strongly suspect the Contract information is >repetitive - so one contract could cover most all the items in the >catalogue - again - dramatically reducing information exchange volume. I quite agree! Which is why the contract information is already referenced from a catalogue and not explicitly included. >The contract information can then also be aligned to local tax >regulations more closely - such as EU VAT - and serve better fit to >purpose roles. I want to help here, David, but I'm not sure where your concerns are. I've found thousands of elements related to <cac:ContractorCustomerParty> through both the document level and the line level ... but I have not found any explicit contract information whatsoever ... only information describing a *reference* to a contract. The party information is necessarily extensive because of the options offered to describe agents, legal entities, etc. But as for simplifying the contract information per se, I don't see where. Note that my analysis is only based on a search of the term "contract" in element names in the XPath files ... of course I may be overlooking the contract information you are referring to. So, can you cite for me which contract information you think should be removed from Catalogue when people are defining their own customizations of UBL? Of course this cannot be "removed" in the UBL 2.1 specification, but for a reader of this mail list archive, they should know that any optional item in UBL can of course be deprecated by a customization that dictates to its community of users that an optional element is not included in that community's specification. I hope this is helpful. . . . . . . . . . . . . . Ken -- World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]