See also: IRC log
-> http://www.w3.org/XML/XProc/2015/02/04-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2015/01/28-minutes
Accepted.
I propose 25 Feb for our next telcon.
No regrets heard.
-> https://github.com/xproc/specification/issues/92
Norm sets the stage...
Loren: It would be nice to have, but it could be very hard to implement.
Norm: I think we'd have to make it optional.
Henry: I think it would be good
if we could do this in a way that operates by only forwarding
the relevant information to the places that need it.
... I think it would be good if we didn't have to implement
schema processing to be an XProc 2.0 processor.
<ht> so that's select="..." as="...", not select="... as ..."
Norm: I think it only bites us where we have sequence types in "as=" attributes.
<ht> Right?
<ht> Yes
Henry, yes.
<p:variable name="hatsize" select="$param - 4" as="my:hatsize"/>
<p:variable name="hatsize" select="$param - 4" as="xs:integer"/>
Henry: What are our obligations under the latter? Is all that we have to do with this is record it?
Norm: No, I believe we have to validate it.
<ht> <p:variable name="hatsize" select="($param - 4) as xs:integer"/>
<ht> if (@x castable as xs:date)
<xsl:variable name="fred" select="(4 - 2) as xs:integer"/>
Norm: That doesn't work "as" isn't allowed there.
<ht> "2003-02-28" cast as xs:date
<xsl:variable name="fred" select="(4-2)" as="xs:integer"/> is the same as let $fred = (4-2) as xs:integer
Henry: Given that "cast as" does
work, I'd like to explore the possibility that we say not just
in spec prose but that we define select=x as=y as "x cast as
y"
... Then import schema is just something that defines the
static context for XPath evaluation, it doesn't cost us
anything.
<jfuller> same thing with constructor func
<jfuller> eg usa:zipcode("12345")
<jfuller> ("12345" cast as usa:zipcode?).
Henry: I don't know if constructor functions work for user-defined types.
Jim: It's equivalent to the cast as expression.
Henry: It also pushes the error handling off to the substrate, which is just fine.
Norm: We should think about this. "as" and "cast as" aren't the same, so we should know what the differences are.
Henry: It seems to me that we need import schema even if we don't use them in as= attributes. We want users to be able to write usa:zipcode in their XPath expressions.
<jfuller> http://www.w3.org/TR/xpath-30/#id-schema-import-processing
<jfuller> seems to align with leaving it to the host language
Norm and Henry speculate about the Saxon API.
Henry: Quoting from XSLT 2.0 if the "as" attribute is supplied then the value is converted to the required type.
Norm: So that is cast as.
Henry: That's on xsl:param, we need xsl:variable.
-> https://github.com/xproc/specification/issues/78
Norm explains: http://www.w3.org/TR/xslt-30/#shadow-attributes
Norm: The question of whether or not xsl:params are in scope is an interesting one.
(Yes, top-level xsl:params are static.)
Henry: Not at the sub-pipeline
level, p:libraries have to be compiled separately.
... I remember distinctly trying to do that with the document
type attribute on the xslt:output statement. The fact that you
can't compute the doctype that you want your output to have is
very annoying.
<ht> I guess I think that's a vnext.1 feature
Jim: I'm not so enthusiastic.
Norm: Sounds like there isn't enthusiasm. Shall we decline this issue?
<ht> I'd like to see how that works in practice for XSLT before committing
Jim: I don't think we need to drop it, but I think we should have some more time to think about it.
Norm: Ok, I'll leave it open for now.
None heard.
Adjourned.