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

["Fraser Goffin" <goffinf@googlemail.com>]

I for one am looking forward to reading the paper. I think this debate
has perhaps run its course until we see Ken concrete proposals.

Fraser.

On 31/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> 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
>
>
> ---------------------------------------------------------------------
> 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/
>
>