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


Tim,
 
OK - I'm trying to finish up what I have on my plate right now that's led me into this quick analysis on UBL.
 
Should have that other stuff together in couple of weeks - then I can start some analysis on what the Contracts approach here should entail.
 
If you create a new transaction interchange as a supplemental pathway - should be possible to run those in parallel - and since the core components are all the same - would allow people to use simple XSLT to morph to/from as needed.
 
At first blush this looks like it has some interesting potential...

Thanks, DW



-------- Original Message --------
Subject: Re: [ubl-dev] Contracts - Simplifying the next version of UBL
From: Tim McGrath <tim.mcgrath@documentengineeringservices.com>
Date: Fri, May 02, 2008 1:50 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "G. Ken Holman" <gkholman@CraneSoftwrights.com>,  
ubl-dev@lists.oasis-open.org

David,

sounds to me like you should join the TC and help us with the next minor 
release (2.1). we are currently gathering requirements so you have 
until June to tell us what you think is required. bear in mind that we 
are not breaking backward compatibility with this next version so there 
are constraints as to what we can do.


David RR Webber (XML) wrote:
> 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
>
>
>
>
> ---------------------------------------------------------------------
> 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]