Re: Five mechanical approaches to make an XSD profile without getting bogged by individual issues

First of all, I would like to thank the TAG for taking the time to 
consider this issue.

I will not pursue this any further here now. I am in no way satisfied 
with the result, which I am sure was reached in good faith; I am sure 
that all the TAG members recognize that its large overlap with XSD WG 
members effectively preludes it from reaching a consensus much different 
from that of the XSD WG. 

I expect to be back with this issue in five years time again, and I 
regrettably expect the same result as 2000, 2004 and now, since there is 
such a strong determination to marginalize small and non-corporate FOSS 
developers.

noah_mendelsohn@us.ibm.com wrote:
> Rick, you imply that the Note produced by the databindings WG calls for 
> subsetting of XSD.  Consistent with the summary of their mandate that I 
> gave in an earlier email, it does not.
Here is how things look from my perspective. It is certainly one-sided, 
but that does not make it unfair or wrong. However, since I have 
actually implemented XSD with a small team, I believe that my 
point-of-view is representative of others in my position, not just an 
individual rant.

The XSD WG had no effective procedures for layering, profiling or 
simplifying XSD.  This disenfranchised a certain constituency, has made 
life difficult for another who are forced to use it, and is biased 
toward corporate developers. This preference for giantism has meant that 
potential members of the WG with different needs leave the WG. This in 
turn means that the WG not only has no effective procedures, but it now 
has a strong disinclination against layering, profiling or simplifying 
XSD. 

When good-faith efforts at the WG forced this issue on to the agenda 5 
years ago, the WG ultimately refused to deal with the issues itself and 
sloughed the issue out to a Working Group specifically chartered in a 
way that to marginalize the problem; disallowing the Databinding WG  
from making anything that might be called a layering, a profile, a 
simplification or anything that might feed back to the XSD WG.

When this issue has been raised we have seen the following responses:

i) These problems are well-known and old hat so go away
ii) These problems are not real because XSD is really popular
iii) People who have these problems can go somewhere else, because the 
XSD WG will not look at them
iv) People who have these problems have already been looked after 
because the WG had a workshop which
resulted in a WG being set up
v) Don't expect the Databinding WG to find any solutions, it can only 
describe the problem.
vi) The XSD WG does not need to look at the solution because it is the 
Databinding WG's province,
vii) There is no expectation that the WG's description of the problem 
will find its way back to the XSD WG
viii) There is no way to solve this problem because people have 
different requirements; the only acceptable subset or profile would have 
to be one that meets all the requirements of the current users
ix) There is only one group that has this problem (databinding) and it 
has specific requirements
x) The XSD WG cannot look into this problem because it is against its 
charter (which, if so, is a maddeningly fatuous argument, as if the 
charter and program of work of the Schema WG is handed down from on high 
rather than reflecting the recommendations and preferences of the WG 
members.)
xi) If XSD cannot be so bad, otherwise RELAX NG would be more popular

The fact that these all contradict or make no sense does not seem to 
matter.

For the record, I would like to note that the discussion was sidetracked 
by the following red herrings: first, the claim that I was asking for 
XSD 1.1 to be thrown away rather than put on hold, second by the idea 
that problems with XSD could be resolved by finding out how many RELAX 
NG schemas were on the WWW, and third by the claim that I am saying that 
XSD is somehow completely unworkable for any use.

Cheers
Rick Jelliffe

Received on Tuesday, 2 June 2009 06:16:08 UTC