Re: [ubl] Re: Thoughts on Ken's UBL Customization document - gkholman-ubl-modeling-0.4

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

At 2006-08-13 10:39 +0800, Tim McGrath wrote:
>Like Stephen, I will not be part of the face-to- 
>face discussion but I am going through this 
>document with great interest (and agreement).  I 
>have only got to the end of section 4, but some 
>of the biggest revelations are that ...
>
>a. The title should be more confident.  I 
>suggest we call this "UBL Customization: 
>subsets, extensions, versions - validation and 
>conformance".  I suspect this will be the focus 
>of the way ahead for UBL and we should grasp the scope from the outset.

I think the UBL Customization document is a 
separate document than this discussion paper.  I 
only meant to convey *my* ideas to the committee 
using this document.  I think the customization 
document will have a different table of contents.

Plus, some of these chapters are more suited to a guidelines document.

>b. I get what you mean by serendipity but jay is right, it is the wrong word.

Accepted.  The committee doesn't have to use this word.

>it really describes the ability to extend reach 
>of trading partnerships without additional programming of interfaces.

Correct.

>It is more like a 'leveraging investment' potential.

I agree.

>b. the application model you paint in your 
>scenarios is not typical. what you describe (not 
>unexpectedly) is a common interface 
>approach.  it describes a new application for 
>creating everyone's documents.  i think we need 
>an application-to-application scenario.

But I thought I was describing an 
application-to-application scenario:  figure 5 in 
section 8.3 is an application generating an XML 
UBL instance, and figure 4 in section 8.2.2 is an 
application receiving an XML UBL instance.

>so it may be better to view this as Training 
>Company's application needs to create CES, ATS,and NES invoice documents.

Agreed.  That was what I was considering.

>Training Compnay dont normally want to create 
>their Invoices and suck it into their 
>application - they want their application to create the Invoice.

Absolutely ... and their application creating the 
UBL instance will be preset for a given 
recipient's specified UBL customization (subset 
plus extension plus business rules).

>They already have their information inside their application.

Right ... and figure 5 shows this happening.

The serendipity is that if a new receiver system, 
typically expecting other business rules, can 
electronically accept the core of instance being 
sent such that the receiver has the core 
information now in hand, then the receiver can 
satisfy the business rules *outside* of the 
instance and the transaction can still happen.

My goal is to find a way such that the software 
is not a barrier to doing business ... that a 
minimum mode of operation of the software still 
allows sufficient information to be exchanged 
such that the recipient can deal with the core 
information without the sender having to take the 
time to re-configure their system.

Again I'm trying to draw parallels with HTML and 
other widely deployed systems where while it is 
desirable to have many things, basic assumptions 
can be made when all the rules are not being met, 
such that there is a lower barrier to entry (in 
the UBL case a lower barrier to a transaction between new trading partners).

>c. you say in 4.3 "I'm not familiar with any 
>other scheme that employs exhaustive 
>enumeration, but I'm feeling more and more 
>confident this is the way to go. The critical 
>nature of this, though, indicates it should be 
>one of the higher priority action items when 
>exploring this approach."  Well 20 years of EDI 
>translation software has been based on this approach.

Ummmmm ... are we talking about the same thing?

>Check out http://www.edi-center.com/edi-translator.htm.
>Basically, what they call an EDI Translator is 
>the application that tests conformity based on a 
>proprietary version of  what you call an XPath 
>text report. What they call a map is the XPath instance report.

Okay ... I've just looked at the page you cited, 
and I think my section 4.3 description is something quite different.

My claim in section 4.3 is that using XPath files 
one can programmatically prove that all instances 
described by a UBL NDR XSD Schema created for a 
customization are instances also described by the 
normative UBL NDR XSD Schema.  Using such a tool 
one can categorically claim the customization 
describes a strict subset without violating UBL, 
and that the normative schemas will validate all 
instances of the customized schemas.

My section 4.3 has nothing to do with 
applications.  Only with schema strict-subset correctness.

>I will respond later when I have completed the remaining sections.

I really appreciate that you've commented so far 
and are continuing to consider the ideas, Tim.

>i am getting a real urge to do some editing and 
>add some diagrams to make it a bit less technical.

ABSOLUTELY!  In my document I'm only trying to 
succinctly convey my ideas for the committee to 
consider in their contemplations.  Any committee 
document will, I believe, be a brand new document.

>Perhaps the next version after the plenary discussions?

Or the first version coming out of the plenary by 
whoever undertakes to write it!

Thanks again, Tim!

. . . . . . . . . . Ken

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