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

[Chin Chee-Kai <cheekai@softml.net>]

On Wed, 31 May 2006, G. Ken Holman wrote:

>>I wasn't proposing RELAX-NG just because I'm a RELAX-NG bigot ... we
>>have real requirements in UBL *that the designers of XSD did not
>>accommodate* but that technologies such as RELAX-NG happen to
>>accommodate.  RELAX-NG was created based on 1960's-era hierarchical
>>database theory that has been applied to hierarchical XML documents,
>>and its validation semantics are published as part of the
>>specification, thus making incorrect implementation impossible (if
>>you implement the semantics as written) because there is no
>>"interpretation" of the standard to be made.
>>
>>For example, RELAX-NG is closed under union, thus if I make a
>>database query from two data sets I can *programmatically* express
>>the document model of the result set from that database query and
>>validate the result set using it ... that is not possible in XSD in
>>the general case.  In XSD I cannot programmatically create an XSD
>>model of the result set of a query of two data sets described by XSD
>>models ... it requires hand-crafting.

Set union, intersection, etc are very nice abstract mathematical 
properties for human to operate with.   It's not surprising that
it facilitates SQL's success with its relational expressions allowing
explicit mention of set unions and intersections in terms of data
instance extraction from the database.  In a document-oriented
database of documents, it would be convenient to use such concepts
to express, for example, a union-selection of all XML instances
having Invoice as main document, and whose BuyerName is such and
such party.  So, yes, I agree with you that in a query, set expressions
would be nice.

But SQL tables (schemas) are certainly not written in set expressions.   
Similarly in XML instances, when we want to define the datatypes of 
each individual fields in detail, perhaps even at such physical 
attributes as  number of characters allowed, lead-trail spaces or none,
etc, XSD comes in handy.

One can't mix the operation of checking the validity of a data (data
being an N-tuple in SQL and an XML instance in UBL) with the selecting
of sets of data from an already filled database.  In SQL, for example,
when one issues "UPDATE ..." command, how does the SQL server decide
whether the given data is valid or not?  Certainly not through using
set concepts, but by going back to the table schema.  Likewise, when
an incoming XML Invoice comes to a user recipient processor, how does
it decide if the incoming data is syntactically valid?  Certainly
not because it can wield the power of RELAX-NG's closure under union,
but by going through XSD's detailed parameters on the individual
fields and cross-checking them with the incoming data.

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.

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.




>>So, from the start of UBL we said we were taking a document-oriented
>>approach to our description of business documents ... to me that
>>means a text-processing approach that supports access by programs
>>because of interfaces to XML instances ... 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).  I don't think we should lose functionality and opportunity
>>in UBL 2.0 because of the deficiencies of XSD.  I'm going to document
>>the methodology and what it will take to use XSD (which appears right
>>now to require NVDL since XSD can't express the requirement).

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.
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.



>>Trust me, Chee-Kai, that I have tried very hard to address the
>>clamour for a pure-XSD solution with respect to extensions.  I'm
>>being told in XML Dev and in W3C Schema that what I want to do cannot
>>be done in XSD.

I agree that there's no need to lose functionality and opportunity
in UBL 2.0, but it won't be because of deficiencies of XSD.  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.

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, then what about approaches to restriction
and other customisation?  Add another description language CONSTRICT-NG?

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.  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.




>>I'll leave it with Steve and Joe to summarize the issues of redefine
>>and substitution since they are obviously more qualified and
>>experienced to summarize their problems ... I'm focused right now on
>>extension.  There are so many special cases and exceptions in XSD
>>that I really have lost the thread on the problems that they were
>>describing.  And it was with your help that I realized that I didn't
>>understand what was going on ... it is more dangerous to think I was
>>understanding when I was not, so I do appreciate that.

I think it's the combined thoughts from everyone participating
in the discussions to unearth the possibilities, pitfalls, and also
implied and indirect consequences.   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, 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.

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 at what consequential cost does it mean?  I've brought up
a number of those concerns in previous few emails.  In addition,
the benefits are not yet certain (ref my points on RELAX-NG above).

But it is also the non-technical issues, not excluding concerns
of current UBL1.0 users who would need further RELAX-NG knowledge
(or buy such consultancy if they don't have) in order to determine 
for themselvse which of your proposed RELAX-NG approach and the
corresponding XSD-based approach (to be included in your paper as 
what you suggested) would fit their own purposes.

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),
business users to whom UBL wishes to target must make reasonable
business decisions regardless of the technical merits.



>>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.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/