Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Hijacked XSD permathread - was Re: Restrictions on existenceof
 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
