[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] RE: Keep business-process-specific data separate?
- From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
- To: "'xml-dev@lists.xml.org'" <xml-dev@lists.xml.org>
- Date: Sat, 31 Jan 2009 12:42:22 +1100
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:
http://docs.oasis-open.org/ubl/guidelines/UBL-Customization1.0prd01.pdf
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
customization
- 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]