RE: Alternatives to XML Schemas
I walked away from my cursory look at TREX with the same impression. I think TREX holds a lot of promise. Conversely, when I was exposed to the details of XML schemas at Guerrilla XML about a week ago, I walked away with the feeling that this is trying to turn XML into a OO style programming language. Maybe I'm wrong but XML schemas made me think, "there has to be a simpler way". Personally, I hope XML schemas do not gain a foothold as a base requirement for XSLT and XPath. Currently, the dependency tree is rather simple. XSLT depends upon XPath and both depend upon XML. How do XML schemas improve upon the current XSLT and XPath standards? J. Keith Wedinger Senior Software Developer Sterling Commerce keith_wedinger@s... -----Original Message----- From: Michael Brennan [mailto:Michael_Brennan@A...] Sent: Tuesday, March 06, 2001 3:10 PM To: xml-dev@l... Subject: RE: Alternatives to XML Schemas [Comments inline] > -----Original Message----- > From: Rick Jelliffe [mailto:ricko@a...] > Sent: Tuesday, March 06, 2001 11:24 AM > To: xml-dev@l... > Subject: Alternatives to XML Schemas > > > Just to note where we (putting users hat on) > > - DTDs remain, providing defaulting and fixing attribute > values even for > non-validating processors (reliable in standalone documents) > and giving a > schema > even though just as documentation I haven't been keeping up too much with this list, lately (too busy with a product deadline), but I did take a cursory look at TREX and the thing that made the most indelible impression on me was the fact that it does not alter the Infoset. I like that. Given some of the debate (that I've tried to catch up with) about growing complexity of XML and increased reliance of various specs on XML Schema, it seems to me that the whole notion of fixing and defaulting attribute values is an unfortunate legacy that is inconsistent with the real XML 1.0 philosophy. When we have the notion of defaulted or fixed attributes, then an XML document cannot truly stand on its own; it requires a DTD or schema for the real intended content to be interpreted. Would others agree? This seems to me one bit of baggage that should be jettisoned. > [...snip...] > I cannot imagine that we won't have some kind of XML Schemas > subset before > too long (indeed, I mentioned this before.) Murata-san and James Clark > clearly have some desire that their Schema languages provide > good models for > such a thing. > > So what would be really useful would be (apart from more > experimentation) > for groups such as XML-DEV and SML-DEV to work up some requirements or > use-cases targetting whereever XML Schemas may be considered > weak. I am > sure that such a list would be greeted by some marketeers as > merely creating > confusion (apparantly this is a great crime rather than the natural > consequence of premature standardization) but, as I mentioned > last week, > from my time in the WG I do think that XML Schemas fills a > good high-end > need--but if someone says it does not fill all needs or some important > use-cases (e.g. related to light-wieghtedness, power, extensbility, > non-disruption of other standards, interoperability issues > for claiming to > be XML but being XML++, etc.) then I couldn't argue with them. The question of whether standardization is being achieved prematurely is a matter of frame of reference. In the EAI and B2B worlds there has been tremedous pressure for something blessed by some vendor-neutral authority so implementors can get on with building the infrastructure for web services. I don't think these implementors are willing to wait any longer. If we come up with something better, it may be too late. It is similar to the quandary we face with HTML vs. XML/XHTML. HTML is entrenched; there is no headlong rush to migrate the web to the latest and greatest because for more practical-minded folks, they have something that works and they want to target existing browsers. Likewise, tools and technologies leveraging XSD are already starting to proliferate. The entrenchment has begun. That won't stop innovation and improvements (just as it didn't stop XHTML). Indeed, in some bizarre sense it may make such innovation easier. Those anxious for a solution now have one (good or bad). The heat is off and innovators can proceed in a less pressured environment; but fewer people are paying attention. If history teaches us anything, implementations of a complex spec will tend to subset the spec and have subtle (or glaring) incompatibilities with each other. I don't think this bodes well for XSD. There is some great work that went into XSD, but I think the XML world needs something simpler. I also think that not every validation task -- or other schema-related tasks, for that matter -- needs a standard. No schema language will fulfill every need, so we really need to indentify some minimal subset that is sufficient for interoperability. I hope that can be done, but realistically I think such an innovation will sit in the shadows of XSD for some time to come, just as XHTML sits in the shadows of HTML today. ------------------------------------------------------------------ The xml-dev list is sponsored by XML.org, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: xml-dev-request@l...
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