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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: Keep business-process-specific data separate?

At 2009-01-30 08:32 -0500, Costello, Roger L. wrote:
>3. "Business-process-specific data versus 
>business-process-independent data" is a false distinction. There is 
>only kind of data: data for some  purpose or purposes, and there is 
>only one kind of XML vocabulary: vocabulary that supports a purpose 
>or purposes.

I would soften that a bit.  What the information in a document means 
is up to the recipient.  Hopefully he is understanding the 
information in the way the sender intended, but he isn't obliged to 
stick to that understanding.  A recipient could choose their own 
document constraints (i.e. schema) and their own stylesheet or 
application to do anything they want with the information captured 
using an XML vocabulary and interpret it any way they wish.

>6. Distinguish between the XML vocabulary you create versus the XML 
>vocabulary that is actually used in practice: when creating the XML 
>vocabulary, identify the optional markup (data) as described above. 
>Recognize, however, that the XML vocabulary may be used in 
>unforeseen contexts that require markup (data) above and beyond the 
>provided by your XML vocabulary. Design your XML vocabulary to 
>support these unforeseen use cases.

One approach is illustrated in figure 21 on page 33 of the draft UBL 
Customization Guidelines:


This shows a processing model with two possible steps for schema 
validation, followed by a separate step for value validation (for 
code lists, identifiers and other business rule values).

Focusing on the two steps for schema validation, a receiver may have 
created a "UBL Customization" comprising a subset of the very large 
UBL vocabulary.  This subset has only those parts of UBL they are 
interested in, and for which they have programmed in their 
application.  Their application may even be constrained to accept 
only the subset of UBL (perhaps they have turned on validation in 
JAXB and an instance is only bound to Java objects if the instance is 
valid; thus in order to inspect anything found in the instance it can 
only have what is expected).

A document arrives at the system and the first schema validation may 
or may not succeed.  If it does succeed, the process continues with 
value validation.

If the first pass does not succeed, a transformation removes from the 
instance all unexpected constructs by only allowing expected 
constructs through an identity transformation.  This transformed 
instance is then validated with the same schema as used in the first pass.

If the second pass does not succeed, there is no point in continuing.

If the second pass does succeed, the process continues with value validation.

So there are two paths that will take content in to an application, 
and the pre-validation ensures the instance will be acceptable to an 
application that uses validation in its data bindings.  The UBL TC 
suggests instances utilize available elements declaring the 
customization and subset to which they conform so that applications, 
when they do get around to inspecting the content, can look at these 
values to make a business decision regarding proceeding.  These two 
paths then bring the instance to the application and the application 
can inspect the declared customization information against the 
expected customization information.

There are four cases:

  No errors on the first pass and the customization is as expected:
   - processing continues and business is accomplished

  An error on the first pass and the customization is as expected:
   - the sender included unexpected information not defined by the 
   - what is in hand is all that is needed, and according to the 
rules of the customization, anything removed wasn't important
   - probably acceptable to do business, unless the community 
dictates that unexpected content violates the rules of sending instances

  No errors on the first pass and the customization is not as expected:
   - this is a foreign instance but there is enough information with 
which to do business and nothing was taken away from the original
   - may want to flag for out-of-band exception handling, but 
probably acceptable since nothing was removed
   - business rules might require rejection if the instance is not 
marked for the customization

  An error on the first pass and the customization is not as expected:
   - this is a foreign instance and some information has been removed
   - something had to be removed to be processed
   - not knowing the rules of the customization, what was removed 
might have been important
   - may want to flag for out-of-band exception handling as one 
cannot be sure the original information wasn't somehow important
   - business rules might require rejection if the instance is not 
marked for the customization

Again, this is all done as a prelude to the application running in 
order to (1) pre-validate the instance as acceptable, and (2) massage 
the instance in order for a validating data binding to pass the 
information to the application.

We've been editing the document and diagrams based on feedback and 
our face-to-face plenary last week, and a new edition is expected soon.

Note that the UBL vocabulary is designed to be both restricted and 
extended (as described in more detail in that document).

I hope this is considered helpful.

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

Upcoming hands-on XSLT, UBL & code list hands-on training classes:
Brussels, BE 2009-03;  Prague, CZ 2009-03, http://www.xmlprague.cz
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS