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