OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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]