OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Hijacked XSD permathread - was Re: [xml-dev] Restrictions on existenceof

[ Lists Home | Date Index | Thread Index ]

Rick Jelliffe wrote:
> . Make up some quality constraints and invite an open source 
> implementation, and let your RELAX NG strategy be "We will distribute 
> it as soon as a non-viral open source implementation comes along that 
> meets our quality requirements for testing and documentation, and uses 
> this API. People can use it if they need, but we provide first class 
> support for XSD only."  People can convert from RELAX NG to XSD if 
> they need to, so you don't need to replace XSD at any other level or 
> tools.
That's similar to the XML team at Microsofts' position vis a vis all the 
XML specs for which we don't supply first class support, and Microsoft 
as a whole has been moving quite a bit in this direction, e.g. 
http://www.codeplex.com/ .  See in particular the MVP XML library.  We 
could and would point people on our platform needing what RNG offers to 
such an implementation, and that would make me feel better about 
advising people to use straightforward RNG rather than an XSD hack to 
solve some specific problem, which is the issue that got Stan and I into 
the original thread.
> My other point was for vendors to use their influence on W3C XML 
> Schema WG so that XSD grammar evolves, albeit slowly, in directions 
> that are consonant with RELAX NG.  In XSD terms, component 
> compatability rather than syntactic compatability.
You seem to considerably over-estimate the influence of vendors on W3C 
> Of course, I suspect MS and other large vendors don't want any change 
> in XSD at all, because of the ramifications, in the same way that MS 
> is not supporting XML 1.1 or XSLT 2. I wonder if Michael has any 
> comment on this? Does MS have any commitment to tracking standards, 
> either for minor-version-number changes or major-version-number changes?
I think you're looking for a grand plan in what is actually 
semi-organized chaos.  To the extent that 70,000 people have a common 
position on any of this, MS wants to promote data interoperability 
across time, platforms, applications, etc. at a reasonable cost to us 
and our customers.  The smaller the number of specs and the more 
gradually and backward-compatibly they evolve, the more likely we 
generally think real data interop will be. For schemas that basically 
means XSD since (for all sorts of good and bad reasons) it's the de 
facto standard and (at least IMHO) Schematron, since it's effectively an 
XSLT application rather than a "new" standard to support.  We'd like to 
see XSD evolve to be clarified, simplified, and aligned with something 
that works around its limitations for things like occurrence constraints 
(probably Schematron rules, again IMHO not Bill and Steve's).  As for 
XML 1.1, we think it is way too little benefit for way too much backward 
compatibility cost (Elliotte Harold puts so nicely 
http://www.xom.nu/faq.xhtml#d0e186 )  and have pretty much laid down in 
the road in front of it.  XSLT 2.0 is just a matter of timing; it will 
probably be supported in the next release of the .NET framework after 
the spec becomes a Recommendation (BTW, Orcas is not a "framework" 
release, only a tools+framework critical fixes release, so it won't be 
in Orcas even if the W3C gets the Rec out this year).

So, a) we don't support every W3C Recommendation or OASIS standard that 
comes out, we focus on those that address real world data interop 
problems; b) we want to see specs evolve in a non-breaking way if 
possible, and in a manageable way if not.  XML 1.1 is a pure example of 
how NOT to do this, IMHO -- there are breaking changes to support 
theoretical interop problems, and there doesn't seem to have been much 
concern paid to the challenge of evolving the installed base.  XSLT 2 on 
the other hand is a good example of how this can be done sensibly, 
albeit with great effort and time. 
> B.t.w., the line that providing RELAX NG will confuse people badly 
> doesn't sit well with me; people manage not be confused that MS 
> provides C++ and Visual Basic and they both are programming languages. 
> A decision point is not confusion. Anyway, if confusion is so bad, 
> what on earth is MS doing with XLinq versus XSLT2 versus XQuery versus 
> SQL? ;-) Now that *is* confusing!
The distinction we see is that schema languages are part of the data 
interoperability contract; if I use XSD and you use RNG to define an XML 
instance we're exchanging, there are going to be some more or less 
inevitable problems along the lines of those illuminated in the parent 
thread.  If I use XLinq to process the data and you use XSLT2, that's 
not going to cause interop problems (well, except possibly for issues 
with things like CData sections or entity references that different 
tools have different levels of support for).  Similarly the experience 
of SQL indicates that real code interoperability is unlikely although 
porting from Oracle to SQL Server is conceptually possibly given their 
common reliance on the SQL standards. Given that  the most practical way 
to get interop is at the level of XML and the "contract" for specifying 
what is expected where in an XML instance, confusion around XML formats 
or schema languages is very bad and erring on the side of stability is 
acceptable.  Given that code-level interop across platforms is difficult 
and rarely achieved, we tend to favor innovation and healthy 
competition.  For example, the competition between C# and Java has 
greatly improved both languages; and the competition among XML infoset 
processing tools has moved us from the options of SAX and DOM 8 years 
ago to  all sorts of new options -- XSLT2, XQuery, various pull 
parsers,  JDOM, XOM, XLinq, etc. during the same period that the XML 
data/schema languages in actual use have remained relatively static. 
That's not to say that format or schema evolution  is  bad or 
impossible, just that evolution needs more coordination and concern for 
backwards compatibility than is necessary in the Darwinian struggle 
among XML processing languages. 

I don't think "Microsoft" has a collective position on this, but I'd 
personally like to see XSD evolve to or be replaced by a modular 
language upon with features such as databinding,  occurrence 
constraints, and relationship management could be built.  That's not 
going to come from another huge committee operating under consensus 
rules, so I'm not sure we even want the W3C to do its thing here.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS