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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


With Jay's permission I am posting a reply 
written yesterday to an assessment he contributed 
regarding the paper being discussed next week.

I just now see Steve has also posted, and I will 
get to that as soon as possible, though I am on 
holiday right now and this will have to wait (hopefully not long).

I hope that the TC finds Jay's observations below and my responses useful.

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

At 2006-07-31 16:10 +0100, Jay Cousins wrote:
>Dear Tim & Ken & all,
>
>As Tim asked a while back (see thread below), 
>some review thoughts on Ken's UBL Customization 
>document - 
>http://www.oasis-open.org/committees/download.php/18849/gkholman-ubl-modeling-0.4.zip.
>
>I looked at this a while ago and have finally 
>found the time to write up my responses/thoughts 
>to this document as I read it.  I wish that I had done this earlier.

Any response is welcome, Jay ... I'm sorry that I 
haven't been able to make the time to respond.

>Notes by section heading and paragraph 
>number.  Many comments, mainly minor in 
>nature.  My main objection was the notion of 
>serendipity which is a word I really wasn't 
>expecting to see in this context. I hope I have 
>not misunderstood what you mean by it, but I found it very confusing.

You are not the only one, yet from my own 
perspective I cannot think of a better word to 
use.  The connotation I'm trying to convey is 
that the system design supports two trading 
partners in a brand new trading relationship are 
able to immediately utilize, without changes, 
their pre-existing UBL implementations configured 
for other contexts.  The WordNet definition of 
"serendipitous" as "lucky in making unexpected 
and fortunate discoveries" ... so as to indicate 
that two existing users of UBL in different 
contexts are "making unexpected and fortunate 
discoveries" in being able to forge an instant 
relationship without having to make changes.

Whether this term ends up in official UBL 
documentation is not important to me, but it is 
working well for me so far in my trial runs of my UBL training class.

>All in all, a very coherent work & I look forwrd 
>to reading the next version in due course.

I suspect the next version will be a committee 
document rather than a personal contribution.

>Really 4 groupings of comments - serendipity, XPath files, xsd, subset.
>
>Hope these comments are useful and not outdated 
>by a gkholman-ubl-modeling-0.5 already!!

Thanks again, Jay, I very much appreciate the time taken to review this.

>(Please excuse typos - I am using an hp in place 
>of my usual toshiba laptop today and the 
>keyboard is smaller and a little different...)

:{)}

>Best regards,
>
>Jay
>
>(Ken - yes, I met you at XML One in 2000 when I 
>first joined RivCom; Daniel Rivers-Moore introduced me to you.)

I look forward to the next time!

>COMMENTS:
>Section 3.1 Read-only UBL XSD schemata.
>2nd para. Propose to clarify how this applies to 
>compatible rather than conformant 
>customisations.  The UBL 1.0 customization 
>document distinguishes between conformant and compatible extensions.

Do you mean the document:

http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/cm/wd-cmsc-cmguidelines-1.0-beta.html

I don't see there a distinction between 
"compatible" and "conformant", though I do note 
that the definition of "compatible" seems 
predicated on XSD derivation techniques.

I discounted the approaches presented 
historically for XSD schema derivation because of 
the research done by Stephen and Fraser into the 
limitations of the W3C Schema mechanisms 
available.  I don't fully understand the 
limitations, I just know that I, too, was not 
able to get the mechanisms to work as required for the project.

>Section 3.3 The "Serendipity Factor".
>1st para.  Sorry, but I and all I discussed this 
>with didn't like/accept the concept of 
>'serendipity' in an e-commerce exchange governed 
>by a TPA.  I see where you are going here but, 
>to be frank, I'd drop the word serendipity and 
>find another word to describe this embracing scenario.

So noted.  I'm sure the committee will agree with 
this as you are not the only to comment in this regard.

A specific comment I've heard is the term conveys 
a sense of "my system was able to be used without 
my authorization", which was never 
intended.  Perhaps this is a sense that has also 
given you discomfort with the term.

>2nd para.  Given the optionality prevalent to 
>UBL I found the second sentence here confusing.

Noted.  Here I'm trying to convey that a 
particular deployment may choose to make an 
optional construct mandatory ... which it 
certainly is allowed to do.  Such an 
implementation, however, could not be party to a 
serendipitous exchange (that is, one between 
implementations configured for other contexts) 
because the sender could very well have not used 
the optional construct and the document is 
rejected because the deployment is expecting it to be mandatory.

>3rd para.  Not sure what is meant by 'incoming 
>instances need to be massaged' - please clarify.

See the discussion in section 8.2.2 and figure 4 for the detail.

>4th para. For me this contradicts the notion of 
>serendipity.  I think if yoy dropped the word 
>serendipity this para virtually provides the essence of this section.

It was my goal for this summary paragraph to 
clarify my use of the word "serendipity" based on 
comments received from earlier drafts.  I've apparently failed to do so!  :{)}

>Section 3.3.1 Example scenario 1 Cross-governmental boundaries
>2nd para.Need to define 'core', please.

Terminology is an issue and in the group process 
the committee needs to establish common 
words.  By "core" I mean "the normative bits 
standardized by the committee", unchanged, upon 
which subsets are based.  I used it first in 
section 3.2, though I didn't define it there.  An 
alternate term I'm considering is "baseline", as 
if to imply you are building on top of it.

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

>4th, 5th para. Good example  of my problem with 
>a serendipitious exchange - it has failed, no? A 
>trading partner has been passed a file that 
>doesn't conform to the file types they accept.

"Doesn't conform" to the business rules or UBL 
optional elements that have been made mandatory are not present.

>If I try and read past the resident geek hacking 
>the invoice (which is giving me nightmares),

:{)}  But I'm not ruling it out!

>the use case steps/workflow here is that the 
>file arrives, the system determines that the 
>file is not valid, the file is pre-processed to 
>augment the file so that it corresponds to an 
>accedpted file type, the file is re-submitted to 
>the invoice system, the system determines that 
>the system is of an acceptable file type and 
>then accepts it.  Putting it differently, the 
>file is validated against structural and business rules upon receipt.

Ah ... not my intention ... these modifications 
and actions I'm citing are being done by the 
*sender* not the *receiver* ... so the receiver 
has rejected the instance and so the sender goes 
through all of the machinations necessary to meet 
the requirements of the receiver.  The geek, 
therefore, works for the sender.  And the sender 
eventually modifies their system to accommodate 
the receiver, using these fallback methodologies 
until such time as their system is changed.

>Final outcome is the system is then upgraded to 
>receive the new file type, which has 
>implicitly,therefore, been added to the list of 
>accepted file types - which happens in the 6th para.

By the *sender* not by the receiver ... in this 
example the receiver implementation is rigid so 
the sender has to make the accommodations.

>Section 4. XPath files.
>
>1st para - typo - missing 'in' before 'XML instances'?

Noted.

>Section 4.3 XPath files for tests of presence and coverage.
>
>2nd para. I can't think of another scheme for 
>implementing 'exhaustive proof of conformance 
>and compatibility' offhand either.  Quite like this.

Stephen and I are finding that XPath files are 
becoming very useful.  Their nascence was for my 
stylesheet development (and I still use them for 
that).  In preparation for the next release of 
XPath files, we are trying to consider what new 
features are needed in the XPath file model.  In 
essence, the XPath file is an XML expression of 
the distillation of the XSD files.  We have type 
information, cardinality, and have made the 
hierarchy explicit.  Can you think of anything 
more we can put into an XPath file that 
developers might want out of the XSD file?

>Seems similar approach to Schematron testing for 
>rules.  I note that you refer to Schematron in 
>Section 8.1.2 Subset supplementatl validation artefact preparation

Yes, Schematron is integral to the value 
validation that incorporates subset needs and trading partner needs.

>Section 6.1 Unable to declare derivatives of the extension point.
>
>Can't be much help here. I find this section 
>difficult to read, sorry, so think I am not 
>understanding the precise problem.

No apology necessary.  I'm trying to put into 
prose an issue that I usually have to wave my arms to describe.

>Given the optionality of the UBL schema ##any 
>giving problems doesn't surprise me. Why ##any 
>and not ##other - to allow extensions from the UBL namespace, presumably?

No, because I cannot do in XSD what I can in 
RELAX-NG:  a "multiple-namespace other".  There 
are many namespaces in UBL, and XSD "##other" 
only can exclude the one target namespace.

For example, in RELAX-NG I can say:

   element * - ( cac:* | cbc:* | udt:* | sdt:* )

which would allow any element except elements in 
any of the UBL namespaces.  There is no way in 
XSD to say "other than the following set of namespaces".

Specifically to your anticipated scenario, I hope 
that no-one defining extensions uses a UBL 
construct as the apex element of their sub-tree.

>I would see problems through the use of xs:any 
>##any leading to a non-deterministic model but 
>you should be able to avoid that with xs:any 
>##other - which I am sure you don't do for a 
>good reason. The xsd problems here include ##any 
>and type extension/restriction limitations as 
>you say.  The way I have approached this kind of 
>problem in the past is through refactoring the 
>type hierarchy, greater use of xs:groups, and 
>thinking along DTD lines - wrapper elements for 
>extension points, parameter entities, 
>include/ignore - to try and think/find a way 
>around it.  If you sent me a schema fragment 
>illustrating the problem then I would likely understand the problem...

I hope the explanation above illustrates why I feel compelled to use ##any.

>Section 6.2 Unable to elide optional elements through derivation.
>
>I think I misunderstand the problem.  I presume 
>by elide is meant remove by xs:restriction.

 From the *middle* of an element's definition.

>If I create a base type with a required and an 
>optional element, say, I can restrict the base 
>type to remove the optional element.  What I 
>cannot do is restrict it to remove the required 
>element. So what is the problem? The only 
>problem I can think of to stop me doing this is 
>restricting across different namespace schema, 
>in which case you couldn't do it.  Is this a 
>namespace issue? Do the schem have same or different namespace?

Perhaps I misunderstand the restrictions of 
restriction.  In XSD can I import a fragment with 
(the shorthand) content model of "a, b?, c+, d*" 
and somehow restrict it to be "a,c" using XSD restriction?

>Section 7.4 Subset UBL conformance
>
>3rd para. typo 'the its business rules'
>
>5th para. typo 'the an absence'

Noted.

>Section 8.1.2 Subset supplemental validation artefact preparation.
>
>3rd para.  Up to here reading Section 8 Subset 
>deployment recommendations I have had UBL 1.0 
>conformant customisation and subsets in mind - 
>now there is mention of extensions.  I think 
>more is needed in the document on extensions to clarify how they are handled.

"Handled" in what respect?  Because of the 
"##any" document model, an instance implementing 
an extension is still a "conformant UBL instance" 
because it doesn't violate any XSD 
constraints.  And since extensions are optional, 
a system accepting the presence of only mandatory 
information items will just ignore extensions.

>For example, on someone taking the UBL model and 
>(having or having not created a subset to meet 
>their needs first) extended it to add vertical 
>industry specific extensions, as in my usage case.

Right ... your extensions go in your namespace 
under the extension point.  When your system 
needs to have access to these extensions, you can 
find them.  Business rules can enforce the 
presence of extension information items with the 
presence of baseline information items.  In a 
"lax" mode of operation of your software, you can 
choose to accept only the baseline information 
items in the absence of your extensions.

>Also, the conformant/compatible distinction of 
>UBL 1.0 customization seems to not be mentioned any more in these guidelines?

I acknowledge that and will review them once again for applicability.

>Section 8.2.2 Application handling of an arbitrary UBL instance input.
>
>the Note. Possibly relevant comment or not - thinking of JDF,

"JDF"?

>you would configure your system to interrogate 
>the schema version attribute and then apply the correct schema to it.

There are a number of element information items for this task:

     <xsd:element ref="cbc:UBLVersionID" minOccurs="0" maxOccurs="1"/>
     <xsd:element ref="cbc:SubsetID" minOccurs="0" maxOccurs="1"/>
     <xsd:element ref="cbc:ProfileID" minOccurs="0" maxOccurs="1"/>

The committee hasn't decided what guidelines are 
used for all of these and their values.  The NDR 
currently has some instance-related rules and 
there is discussion of removing the 
instance-related NDRs into a separate guidelines document.

Furthermore, your example of interrogating the 
value and selecting the schema avoids an issue 
under discussion that points out it is not 
possible to validate that a value in an instance 
matches the schema version value in the schema 
being used (post selection of which schema to use).

>Section 9. Future work
>
>1st para. typo 'these up processes'

Noted.

>//END


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]