[
Lists Home |
Date Index |
Thread Index
]
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
|
