RE: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema Extensibility

["David RR Webber \(XML\)" <david@drrw.info>]

Ken,

Clearly the misunderstanding is with people believing that W3C Schema is
a business validation technology.

It is not.

Primarily its role is to describe the structure and layout of XML
instances and permutations in those structures and perscribed varients.
 

Even then - it only describes all the possible permitted structural
variances - not the actual instance structure required for a particular
interchange for a particular role and context usage.  

Along with this is the ability to provide a content model - such as
dates, decimal, integer, token, etc.  Again people confuse content
model with business validation.  Clearly the lack of role and context
expression in XSD mean that only the most general content models can be
used that match all possible uses for all structural permutations (least
common denominators only).

Predominantly I see that people use the schema for such structural and
content model checking in an XML parser pre-check pass and then
immediately unmarshall the XML into some other format (eg Java VOs) and
then perform business validation checks via the programming tool of
their choice - Java, VB, Python, et al.

Now of course we also have XML-aware rules technology that augments the
strict structure and content modelling that XSD provides - such as CAM
and Schematron - and provides means to use role and context
particularly.

Also - XSD is deliberately a small-world, standalone footprint solution
designed to be used with a parser - whereas tools like CAM give the
ability to reference external registry services and associate content
to a reference vocabulary and dictionary (such as UBL) to aid
information alignment and semantic understanding.

I believe we have established that the best practice here is to use XSD
just for structural definition and content modelling - but then to
extend this with a second layer that supports context, role and
business validations directly.

DW

 


 -------- Original Message --------
Subject: Re: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema 
Extensibility
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Date: Tue, May 16, 2006 9:31 am
To: UBL-Dev <ubl-dev@lists.oasis-open.org>, "XML-Dev Mailing list"
<xml-dev@lists.xml.org>

At 2006-05-16 13:42 +0100, Fraser Goffin wrote:
>H'mmm, I been discussing some of this with my colleagues. One things I
>am slightly concerned about is 'raising the bar' too high for some
>service consumers.

But if it isn't high enough to clear the obstacle behind the bar, 
then you'll trip over the obstacle after clearing the bar.

>The default way that most people validate messages is via XML schema

Yes, some W3C Schema religion adherents believe that is the only way 
to work with XML.

>and the standard features of a validating parser.

... that are limited in functionality to address some of the 
real-world problems of working with XML.

>Where that schema
>includes extensibility, then the communicating parties can choose
>whether to take account of the content in those locations (if they
>have a schema on which they have both agreed), or ignore it. Using
>processContent = 'lax' most closely supports this approach, whereas
>skip just ignores content altogether..

I disagree that it closely supports the approach when the approach 
is, explicitly, the definition of an opaque black box that is 
relegated to other responsibilities.

>As you know I am also interested in NVDL, partly because it supports
>other ideas we have about selecting only those parts of a message that
>are of interest to us and ignoring anything else (a form of 'must
>ignore' pattern).

Indeed the black box is such an thing.

>However, using mechanisms such as NVDL or writing
>something yourself that does soemthing similar, means that in a large
>community you may be either forcing everyone to meet this level of
>processing sophistication, or be removing the possibility of
>performing at least the default validation processing provided 'out of
>the box' by most validating parsers.

I had this very discussion this morning in a teleconference.  If the 
problem to be solved cannot be addressed in its entirety with a given 
technology, then other technologies need to be involved producing, I 
suppose, the "processing sophistication" to which you refer.

And layering different technologies is a straightforward process, not 
a sophisticated process, and without them the entire problem is not
solved.

>Hence my earlier comment about
>whether in the face of using extensibility in schema, the criticality
>of NVDL is reduced.

Only if extensibility in W3C Schema is sufficient to the task at 
hand, and I believe it is not.

>That is, assuming you just wanted structural
>validation, why wouldn't you just load up your parser's schema cache
>with all of the schema that you are interested in validating against
>including any from any of the xs:any extensibility points (sorry just
>having a bit of fun seeing how many times I could say 'any' in one
>sentance :-).

:{)}

Because (1) there are non-structural-validation issues that are part 
of the entire problem that won't go away, and (2) the usability of 
UBL extensibility of xsd:any using W3C Schema has not been proven 
(yet).  I would welcome someone illustrating successful extensibility 
of the read-only UBL schemas being produced next week with the 
extensibility points ... though that still wouldn't address all of 
the problems to be solved.

If "raising the bar" allows clearing problems to be solved that 
cannot be solved with the current placement of the bar, that should 
be enough impetus to take on some lifting.

It has been difficult to illustrate to people who genuinely believe 
that W3C Schema solves all problems that there are problems for which 
it is ideally suited and there are problems for which other 
technologies are absolutely required to be used in its place.

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

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:  Varo, Denmark 2006-09-25/10-05
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the
UBL OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/