This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Schemas in XSLT 2.0 (Was: Re: keys and idrefs - XSLT2 request?)


> Yes this view has my sympathy as well. It's a real worry that while
> Xpath 2.0 is coerced into being a carrier for XQuery, many of the extra
> features being added have rarely or never been requested by XSLT users,
> In particular schema support doesn't seem particularly high on many
> people's wish list. and many features that have been requested are being
> delayed. Multiple file output, grouping, evaluation of dynamically
> constructed XPath expressions, etc. It would have been nice to
> see an XSLT 1.x with these things in, rather than have everything pushed
> back to a 2.0 that still hasn't even come out as a first draft, and
> judging by the functions and operators document will be somewhat
> preoccupied with schema support.

Good. I'm glad to know that I'm not the only one who felt that 1.1 was
essentially pushed aside to apease the database and SOAP crowd, which is
what I see driving Query.

> As for your point 3, I agree that being locked into W3C schema at this
> stage when there is so little experience with schema, and there are
> clearly going to be multiple schema languages used with XML would be a
> bad thing. This is why earlier I highlighted the difference between
> supporting the built in types (that could also be used for example with
> RELAX NG) as opposed to requiring (or encouraging) full W3C Schema
> processing before transformation, which is likely just to make worse
> the kind of compatibility problems associated with dtd defaulting

Here's are instances of where I see things getting ugly with schema in XSLT:
- ordering of complex types,
- even more damned namespace declarations than we could possibly need or
want,
- runtime schema validation slowing things down even farther,
- incompatibilities with document() and xsl:document because we introduce a
data inheritance hierarchy model over what was a clean, simple declarative
architecture,
- backward compatibility issues

I could see support for primitives, could even see the inclusion of a regex
engine (which should have been in there from the first), but given the
inherent (and personally unnecessary) complexity of XML Schema, I worry that
this will simply be another excuse to bury XSLT so far down in the
infrastructure of vendor products that it will end up disappearing
altogether.

-- Kurt Cagle






 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]