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

noah_mendelsohn@us.ibm.com wrote:
> I think it's also worth noting that in my informal discussions with people 
> from the databinding community, it's not at all clear that the profiles 
> they wanted were the ones that either you or I would consider interesting 
> to make XSD cleaner.  As I recall, the two features that came in for the 
> most regular criticism on XSD from that community were:
>
> * mixed content
> * <xsd:choice>
So why are they so sacrosanct that they could not be barred in a profile?

I just don't get it, I am afraid.  It is the argument I mentioned 
before, that we cannot make a profile that
misses out on some major functionality or aspect, when surely that is 
the point of a profile.  

Now I favour a profile that is also a core, and is derived mechanically 
(as in those 5 approaches) to
the paralysis-by-analysis and potential for stymie-ing that could come 
from dealing with individual
issues.  But even with the issue-by-issue approach, the leading 
candidate for requirements already
exists, with the Databinding WG's reports: that would also be possible.

Would it be right to say that the XSD Schema WG does not consider that 
support for users
who currently find full XSD 1.1 too large/complex/over-engineered is a 
vital part of its mission?

Cheers
Rick Jelliffe?

Received on Monday, 25 May 2009 05:42:13 UTC