RE: [ubl-dev] Re: Global elements doing UBL a disservice

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

It is unfortunate when not talking face to face that one cannot 
detect the confusion early in order to intercept tangential 
discussions.  I'm going to try and rein in the discussion to a few 
points and attempt to clarify what I was trying to say.

At 2006-05-31 16:00 +0800, Chin Chee-Kai wrote:
>On Wed, 31 May 2006, G. Ken Holman wrote:
> >>I wasn't proposing RELAX-NG just because I'm a RELAX-NG bigot
>...
> >>RELAX-NG was created based on 1960's-era hierarchical
> >>database theory that has been applied to hierarchical XML documents,
>...
> >>For example, RELAX-NG is closed under union
>...
>
>Set union, intersection, etc are very nice abstract mathematical
>properties for human to operate with.

My point was not that it being closed under union helps with the 
definition of UBL 2.0, my point is that RELAX-NG has more expressive 
power with less interpretation through which incompatibilities 
between implementations can cause difficult in deployment.  I 
apologize that it triggered a discussion of set expressions that does 
not relate to my point.

>So when you bring up RELAX-NG's set closure under union operation,
>I don't find it as a strong argument as being more helpful to end-user
>operation either.

For that I apologize, as that was not my intent.

>But more importantly, it is not on their individual technical merits
>among XSD & RELAX-NG that I'm having difficulty reconciling, but rather,
>on their consequences when put together, at this juncture in time,
>as per what you intend to do in your paper.

My point wasn't the putting of these together, but the contrast of 
the expressive power of these two, where XSD does not meet a UBL 2.0 
requirement completely and RELAX-NG happens to do so.

And I am committed to document a pure-XSD expression that, while it 
doesn't satisfy the requirement, is shown where it is sufficient so 
that users can assess what to do with those deficiencies.  I'll also 
document technologies with which users can address those deficiencies 
while using XSD, but those other technologies are not XSD.

> >>I'm just showing that XSD
> >>does not handle all of the requirements as our requirements evolved
> >>from UBL 1.0 (which it did handle) to UBL 2.0 (which it does not
> >>handle).
>
>If UBL1.0 can do it nicely without RELAX-NG, and now somehow
>requirements in UBL 2.0 goes beyond what XSD can offer,
>I won't be so ready to put the blame on XSD, but to also
>see if such demands on XSD can be done in other ways.

Which is why I went to the experts in the XML-Dev and W3C Schema mail 
lists to solicit their opinions which supported my observations of 
not being able to do what is needed.

>So, I'm glad you're going to document the methodology on using XSD
>to do exactly the same as what the proposed RELAX-NG could do.

That I cannot do ... I've been trying to explain that XSD has 
deficiencies that will leave small holes in implementations and 
document what the holes are so that implementers can decide what to 
do about the holes.

> >>Trust me, Chee-Kai, that I have tried very hard

As to your last comment at the end of your message, I'm not asking 
you to trust my technical conclusions ... you can make your 
assessment of them when I'm done (but I'm spending a lot of my time 
on UBL-Dev these days).  My comment was only that I was trying very 
hard and I wanted you to trust I would not lightly make the 
recommendations I am making without checking the resources I had 
available.  I would *gladly* be corrected and shown that what needs 
to be done can be done in a pure XSD implementation:

   RELAX-NG (which meets the requirement):

     element Extension { element * - ( in:* | cbc:* | cac:* ) ...

   XSD (the incomplete solution with holes):

     <xs:complexType name="extension">
        <xs:sequence>
           <xs:any namespace="##any" processContents="skip"
                              minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
     </xs:complexType>

There is another more important area of extending the extension area 
with the validation of a given set of extensions, but I'll put that 
in the paper.

>I agree that there's no need to lose functionality and opportunity
>in UBL 2.0,

Good ...

>but it won't be because of deficiencies of XSD.

Then I see a contradiction.

>The
>development of a spec, amongst many objectives and responsibilities,
>is precisely to find a good tradeoff between
>
>- what's in the market now
>   (e.g. stability of XML/XSD specs, availability of XML/XSD tools,
>   familiarity with them by users, some level of buy-in established
>   with UBL1.0, etc),
>- what's going to become (that the world's business community,
>   at least possibly 80% of them according to UBL's 80/20 rule,
>   would use UBL), and
>- what the users are willing to take to buy in.

UBL 1.0 use and experimentation has led to requirements in UBL 2.0 
that are needed to meet the user communities stated intentions of 
working with UBL 2.0.  If XSD cannot meet the requirement alone, then 
implementations will have to find ways to augment XSD to meet the 
requirement.  I'll be showing some available technologies with which 
to do that, but of course they could choose to implement bespoke solutions.

>If, say considering all aspects and factors, you've really come to
>the conclusion that RELAX-NG is needed for extensions in order just
>to support extensions,

No, I'm trying to say that when I document the restrictions of XSD 
implementers will have to choose to live with those restrictions or 
accept the use of NVDL to meet the requirement so as not to have to 
write bespoke solutions.

It is unfortunate that my references to RELAX-NG to explain the 
problem are leading to the conclusion that I am pushing RELAX-NG on 
users for the solution to the problem.  I don't recall ever saying 
that one has to use RELAX-NG.  It merely has a convenient syntax with 
which I can document the requirement and illustrate how XSD does not 
meet the requirement.

In fact in my paper, Chee-Kai, I anticipate proving that XSD + NVDL 
satisfies the validation requirement sufficiently well.

>then what about approaches to restriction
>and other customisation?  Add another description language CONSTRICT-NG?

Sorry, Chee-Kai, I lost you there.

>I realise that if your assigned role in TC is just to look at extension,
>the question does not seem fair to you.  But I think a customisation
>"strategy" using patch-wise refinement by successive inclusion of
>more description language(s) doesn't give much sense of stability and
>reliability.

That is unfortunate.  But you've made a lot of conclusions based on a 
paper I haven't written yet.

>A consistent customisation strategy would need to examine
>all aspects, or at least the more frequently used aspects, of
>customisations and handle them almost in a unified manner.  That's
>ideally, of course.  But is this expectation too far from what's
>available to make it happen?  I doubt so either.

But to sacrifice what I understand from users to be key UBL 2.0 
functionality not provided by UBL 1.0 seems to be throwing the baby 
out with the bath water.  If implementers and users can live with the 
holes present when obliged to use a pure-XSD implementation, they can 
go ahead and do so.

>I think it's the combined thoughts from everyone participating
>in the discussions to unearth the possibilities, pitfalls, and also
>implied and indirect consequences.

Which, Chee-Kai, is why I've brought this up in the forum.  Rather 
than criticizing my as-yet-undocumented conclusions as being 
insufficient to the task, contributing a pure-XSD method of 
expressing the need expressed formally above would be a very helpful 
contribution from anyone in the list.

>While I see that going further
>into a pure-XSD approach might encounter some creative exploration,
>maybe some back-tracking to try another route and so on,

I heartily encourage someone to do so ... if I could have avoided 
such confrontation on this list that I hadn't anticipated, I would 
surely have chosen to do so.

>there's
>the end-result argument (UBL infoset is still an XML infoset and
>hence certainly describable by XSD)  supporting the view that this
>(pure-XSD) is not a dead-end approach.

But as you know, Chee-Kai, one does not use XSD to describe an XML 
infoset, one uses a constraint language such as XSD to express the 
constraints on an XML infoset.  And all along I have been complaining 
that the constraint semantics available to be expressed in XSD do not 
meet the constraints we need to express for UBL 2.0 instance 
validation of extensions.

>I don't doubt your technical assessment that if you bring in RELAX-NG,
>you could do what you want (on customisation of user schemas, etc).

But if you review what I have been saying, that is not what I've been 
advocating.  I was merely using RELAX-NG to document the 
requirement.  In fact my validation component of my paper talks about 
using XSD and NVDL to meet the requirement as an alternative to using 
RELAX-NG.  Yes, it happens that RELAX-NG will be shown as an 
available alternative, but I'm not trying to be a RELAX-NG zealot.

>Put aside any sense of betrayal that UBL1.0 users might feel (afterall,
>UBL spec didn't say UBL cannot use other schemae presentations in
>future; fine), if the means (of additionally needing RELAX-NG) don't
>justify the ends (of just simply validating incoming XML instances),

Then if implementations wish to meet the task without complete 
validation of incoming XML instances, then they can choose to do 
so.  Validation is a luxury with which implementations can be free of 
the burden of checking the structure of information in a bespoke 
fashion.  If they wish to take on that burden, they can choose to do so.

> >>For every group of users that I'm talking with regarding extension,
> >>they are asking me to come up with a pure XSD solution to our
> >>requirement, but how can I give that to them when XSD semantics do
> >>not support our needs?
>
>You've asked me to trust you;  I trust you can.  Indeed, all the
>groups of users you mentioned trusted that you could.
>Don't give up so easily.

:{)}  I only asked that you trust that I tried hard ... I cannot do 
the impossible by making a silk purse out of a sow's ear.  I will 
gladly yield the floor to someone who can show the pure-XSD 
implementation of the constraint semantics I'll be describing in the 
paper (when I can get the time to work on it) ... I welcome the 
opportunity to learn.  I'm sure the XML-Dev and W3C Schema experts 
I've called upon will be pleased to be shown as well.

But I will need time to actually write the paper.

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


--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO/UBL training: Varo,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/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