> I wonder if anybody in the real world actually create cross processor
> XQuery code.

XQuery is interesting in that in several places it allows implementations
to fail (unless it has changed) if they cannot for example figure out how
to convert an XQuery into their native query capabilities.

So this is a very different view of what standards are supposed to do: it
is a standard as a range of syntaxes rather than as anything that allows
product substitutability. That is a quite practical, but allowing, in
effect, vendors to choose which features they implement is not what many
people expect from a standard: if it involves the features you are
interested in, you think you have been sold a pup.

On the immediate issue of XSD, there is no technical reason to disallow
support for element substitution groups for data-binding, as far as I can
see. A schema that uses them can be transformed into an equivalent schema
that uses them: in this particular case I don't see why they technically
provide any obstacle to databinding tools, since they don't rely on any
target capabilities (i.e. they are an injection mechanism, not a different
component IYKWIM.)

XBRL uses element substitution groups, so it is quite an important feature.

So what is the reason? That XSD is just too damn big to be implemented
fully by many system, not on technical reasons but for commercial reasons:
the cost of the extra features are too much. This is surely the fate of
large monolithic standards which don't allow proper layering or proper
subsetting.

Cheers
Rick Jelliffe

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php