RE: Alternatives to XML Schemas

["Wedinger, Keith" <Keith_Wedinger@stercomm.com>]

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@stercomm.com


-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@Allegis.com]
Sent: Tuesday, March 06, 2001 3:10 PM
To: xml-dev@lists.xml.org
Subject: RE: Alternatives to XML Schemas


[Comments inline]

> -----Original Message-----
> From: Rick Jelliffe [mailto:ricko@allette.com.au]
> Sent: Tuesday, March 06, 2001 11:24 AM
> To: xml-dev@lists.xml.org
> 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@lists.xml.org