Jon Smirl XSLT 1.1 Reqts Comments

This guy emailed me directly. Forwarding a summary of
the email trail for archiving purposes...

From: "Steve Muench" <smuench@us.oracle.com>
> Jon,
>
> | 1) How about adding a way to optionally specify an input schema
> |    and output schema. The output schema is useful for
> |    validation. The input schema is very valuable to an XSLT
> |    compiler.
>
> Our rule of thumb for the scope of 1.1 is that it is limited to the
> standarization of features that are already implemented and used by
> XSLT users in two or more existing XSLT processors. The XSLT 2.0
> project is more ambitious and is the place where "new features" are
> being considered. There are already several XML Schema related
> features under consideration for 2.0

I'm not asking for a requirement to do anything with the schemas. I'm
just asking for a syntax to add them to the stylesheet.  Can we bring
this much of the 2.0 proposal into 1.1?

> Please propose a pseudo-syntax and couple of sentence description
> for exactly what you're talking about so I can be clear about it
> Is this an <xsl:output> hint of some kind, along the lines of
> doctype-system and doctype-public? Or something else?

How about:
 <xsl:output schema=string />
 <xsl:input schema=string />

The output schema should be there for the same reason doctype is
there. The input schema hint would be used by an XSLT compiler to more
efficiently compile the sheet. Input schema support is optional so if
it's specified and the processor doesn't understand it, it's just
ignored. There should probably be an input doctype hint too.


> | 2) URLEncode should be a built in function.
> |
> | 3) We should have a format date equivalent to format number.
>
>
> With a portable extension function mechanism, the ability to
> incrementally add portable functions like URLEncode and date
> formatting becomes much more straightforward.

I picked these two since I've received about 5,000 requests to add
them to the system I work on. These are very basic functions that
should be part of the core.

> | 4) There are significant problems with shallow vs deep includes
> |    and wild card patterns. James Clark and I traded a bunch of
> |    emails on this without coming to a conclusion. The best
> |    solution is that XSLT needs to be able to include another
> |    sheet and optionally not include the sheets that it includes
> |    (shallow include option).  
>
> Do you have any pointers to  this email trail for background info?

No, the discussion is from about 18 months ago and my archives only go
back a year. It boils down to something like this:

sheet A has a default wildcard pattern
sheet B is used standalone and includes A
sheet C is used standalone and includes A

sheet D is used standalone and includes B and C
The fact that C includes A with the wildcard makes sheet B inaccessable.

Two solutions:
1) Sheet D includes A, then includes B and C with a shallow include.
2) Stylesheets are marked so that they are only included once.

There is no solution for this in current XSLT.

Because of the way match="*" is processed in the second include of A
it will always be matched before any of the patterns in sheet B. The
double include of A causes all of the patterns in A to be
redefined. This may be processor dependent; XT made B inaccessible.
The basic problem is that there is no way to control the double
include.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/

Received on Thursday, 31 August 2000 10:40:52 UTC