[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]