Information items in 2-prd2-cd minimal instances

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

As part of the analysis of 2-prd2-cd in the 
context of the extension methodology and my 
concepts of working with minimal instances of 
only mandatory elements, I thought it best to 
supplement the XPath report files with a "minimal 
mandatory report" for each of the 31 document types:

   http://www.oasis-open.org/committees/document.php?document_id=19695

Each report enumerates the absolute minimum 
mandatory element and attribute information items 
for the given document type.  The smallest 
instance that would validate with the schema 
would be an instance with only (and all) these information items.

The reference numbers at the left are the XPath 
reference number from the complete XPath file 
that enumerates one of every information item.  I 
am unable to put the complete 283Mb XPath package 
in the repository, so I've corresponded with 
OASIS staff to see how I might do this.

By reviewing the minimal instance information 
items, I wonder if the UBL subject matter experts 
might detect any faults in the model design.

I was interested to see what information items 
are, I believe, those that would need to be 
supported in a "minimal implementation" as I 
described to Jay in my response quoted below.

While the vast majority of transactions accepted 
and processed by a system would be instances 
meeting all of the business rules of the 
recipient, in a "minimal mode of operation" 
selectively engaged by the recipient in order to 
transact with a new business partner not meeting 
the business rules, the system could act solely 
on the minimal mandatory information which is 
guaranteed to be found in instances of *all* UBL 
implementations.  This suspension of business 
rules would not be the norm as eventually the 
sender would change their system, or the 
transaction with the sender might just be a 
one-off, but for that period of time that the 
sender does not meet the complete business rules 
of the receiver, the receiver could transact 
(with the required non-electronic support 
information) with the minimal instances.

The question is, are there sufficient mandatory 
information items in the minimal document models with which to do this?

I hope this is considered helpful.

. . . . . . . . . . . . . Ken

At 2006-08-11 10:11 -0500, I wrote:
>At 2006-07-31 16:10 +0100, Jay Cousins wrote:
>>3rd para. So serendipity is conformance to the 
>>UBL model *without* extensions - yes?
>
>Yes.
>
>>- which makes perfect sense - but for this a 
>>UBL compliant system would need to implement 
>>the entire UBL model, including all optional content, no?
>
>I don't think so ...
>
>For example the absolute minimum invoice 
>instance has only the following information items:
>
>/in:Invoice/
>/in:Invoice/cbc:ID
>/in:Invoice/cbc:IssueDate
>/in:Invoice/cac:AccountingSupplierParty/
>/in:Invoice/cac:AccountingCustomerParty/
>/in:Invoice/cac:LegalTotal/
>/in:Invoice/cac:LegalTotal/cbc:PayableAmount
>/in:Invoice/cac:InvoiceLine/
>/in:Invoice/cac:InvoiceLine/cbc:ID
>/in:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount
>/in:Invoice/cac:InvoiceLine/cac:Item/
>
>>If not how can serendipity apply? It's not 
>>clear to me if the minimum requirements are 
>>stated or not.  I assume that 'minimum 
>>requirements' are support for the whole UBL model.
>
>Personally, I think that 'minimum requirements' 
>is support for only the mandatory elements.
>
>If an invoice processing system supported only 
>the absolute minimum elements above, and the 
>invoice gets paid without need for *any* 
>optional elements, then payee gets his money 
>from the payer without either having to change 
>their systems.  Obviously this would probably be 
>an optional mode of operation, as having a 
>number of the optional items would often be 
>required to meet business needs by the paying 
>organization.  But by encouraging deployments to 
>have such a mode of operation, then two brand 
>new trading partners could use their existing 
>implementations of UBL with an agreement to 
>work, perhaps just one-off or for a temporary 
>period of time, in this "minimal mode" until 
>such time as their systems can be modified to meet more business requirements.
>
>Without propagating this concept of being able 
>to work, even just optionally, in such a minimum 
>mode of operation, I'm worried that UBL 
>deployments will create obstacles for new 
>trading partners to either quickly or just 
>temporarily do business by mandating changes to existing implementations.
>
>>However, Section 5 of the document shows that a 
>>system that does support the UBL model is 
>>'UBL-open'.  So I think the meaning here is 
>>that serendipity requires a UBL-open system?  Can you make this explicit?
>
>Yes, my thought was that a UBL-open system is 
>one that supports the absolute minimum in a mode 
>of operation that suspends business rules that 
>would otherwise cause the instance to be rejected.
>
>Whereas a UBL-conformant system is one where the 
>business rules are not suspended and a 
>UBL-conformant instance not meeting the rules is 
>rejected, but one that does meet the rules is accepted.




--
UBL/XML/XSLT/XSL-FO training:         Vårø, Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal