- From: Rick Jelliffe <rjelliffe@allette.com.au>
- Date: Tue, 02 Jun 2009 16:15:18 +1000
- To: noah_mendelsohn@us.ibm.com
- CC: www-tag@w3.org
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