Accept this agenda?

-> http://www.w3.org/XML/XProc/2015/02/04-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2015/01/28-minutes

Accepted.

Next meeting

I propose 25 Feb for our next telcon.

No regrets heard.

Do we need p:import-schema

-> 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.

Should we adopt shadow attributes?

-> 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.

Any other business?

None heard.

Adjourned.