[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: Global elements doing UBL a disservice
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/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]