[
Lists Home |
Date Index |
Thread Index
]
bryan wrote:
> Although I definitely don't want XSDL support in XSLT I don't
> necessarily think your argument there holds, I mean just because
> Programmer X can achieve solution Y based on an advanced knowledge of
> two different technologies(z,z2) does not invalidate the desire of
> others to make the building of such solutions simpler. Not to imply that
> I think xslt 2.0 is going to make the building of such solutions notably
> simpler.
I admit my statement was a bit simplified: The fact that I can do "lint"-style
checking without schema support doesn't in it self prove such support
to be a bad idea. But I think "lint"-style checking, however important
it may be, isn't a broad enough reason either, and misses the mythical
80/20 mark by far. This isn't something that every XSLT user will
hack by them sleves. They will just happily use tools made by others.
(BTW, how much help would I get from an XML Schema aware
processing language when I want to check my stylesheet against
a RELAX NG schema?)
Another idea about schema support:
-----------------------------------------------
If schema support must be added to XSLT I think it should be very
generic and non-intrusive. One idea I've been thinking about is to use
a schema axis together with a suitable abbreviation. What nodes to expect
on the schema axis should not be specified in the XSLT specification,
but in separate specifications for each schema language.
There could however be top level elements that provide a standard
way to assoicate a stylesheet with a schema. Something
along the following very hypothetical example:
Schema fragment (in the RELAX NG compact syntax):
value = element foo { xsd:int } | element bar { xsd:anyURI }
Stylesheet fragment (assuming '#' for the abbreviation of 'schema::'):
<xsl:load-schema href="myschema.rng"
type="http://relaxng.org/ns/structure/1.0"/>
<xsl:template match="schema::value">
<xsl:text>Value: </xsl:text><xsl:apply-templates/>
<xsl:template>
<xsl:template match="#xsd:int">
<xsl:text>Integer: </xsl:text><xsl:value-of select="."/>
</xsl:template>
<xsl:template match="#xsd:anyURI">
<xsl:text>URI: </xsl:text><xsl:value-of select="."/>
</xsl:template>
New FXPath features:
-----------------------------------------------
> By the way was looking at fxpath again recently, do you have any
> problems with someone building a partial implementation, reusing bits
> etc.
No problemo, be my guest. I developed it a bit further internally with the
most notably change that functions are now first class expressions/values.
They can be stored in variables and passed as parameters and return values.
However, to write a recursive function you would still need to bind it
to an extension function name at the top-level. I also added a generic
suffix call operator: any expression followed by an argument list is treated
as a function call. The function keyword got abbreviated to 'func'.
This example expression summarize the changes:
$add := func ($x, $y) -> $x + $y; $add (1, 2)
Cheers,
David
|
