See also: IRC log
Amended with item 3, a advisory type attribute for p:option
Murray and Alessandro give regrets for 30 Aug
In particular, 5.7.3 and other recently changed areas per recent email.
Henry: I'm happy with it and I
think Jeni's suggestions are all good and not serious.
... I would say that when you've worked through the motivation, just above the tableau, there's the sentence "the p:namespaces option can be used to provide bindings"
... I think it should be made clear here that it can be used as an option of p:option or p:parameter.
... I got to this point and couldn't remember where it went.
Norm: I agree; I'll fix
... Any other comments?
... Anyone else willing to step up and commit to careful review before COB on Monday?
Mohamed, I'd like more annotations on the types for this review.
scribe: I think there are some
things about option types that are not clearly stated.
... In particular the distinction between XPath select and XSLT patterns.
Henry: I read Mohamed's recent
email suggesting that we ought to have a way of providing an
advisory type attribute on p:option.
... I have mixed feelings because what point is there in having something advisory in the language
... I can imagine harvesting from someone's declarations and producing a schema.
... I wonder what the downside is?
... Of offering a type attribute on p:option and p:parameter?
Norm: And c:parameter?
Henry: Uhm, I haven't thought that one through; yeah, I suppose so.
Norm: Are implementations required to test the types?
Henry: Absolutely not.
Norm: So they're just strings of any sort.
Henry: They're a privileged kind of documentation
Mohamed: It's just like the core steps in the language.
Alex: Are you expecting these to be QName values?
Henry: I'll probably use QNames, but I don't think we should require them.
Alex: So then, don't we have a namespaces problem?
Henry: These types aren't going
... What this enables me to do is derive a schema from a set of declarations which I can use to check pipeline documents that use the short name form of options.
Richard: These appear in the pipeline document
Alex: The most likely thing is XML Schema simple types.
Henry: Alas, there's no normative name for XPath expressions.
Norm: If we don't say what these things are, then we can't check for valid bindings. A string with a colon isn't necessarily a QName.
Alex: Since the namespaces stuff is all there, you're assuming that a program would use in-scope namespaces to find the value.
Henry: The type is being specified by the pipeline author, not the caller. So the author knows what the namespaces are.
Norm: It's just documentation
Henry: It's not part of the enviroment
Alex: Then I'm totally against this.
Henry: It's only available for options during option declaration.
Alex: Ok, then it should become part of the declaration.
Norm: Pipeline processors are not supposed to check.
Alex: That doesn't make any
... We'd provide a facility that has an obvious interpretation and then not allow you to check that.
... That seems weird.
Murray: I sort of agree with
Alex, but perhaps not as vehemently.
... Why isn't this an attribute in your names/ace?
Henry: Because I think it'll be common enough that we might want to standardize it.
Norm: The other point is that it could then appear in the spec (in the declarations of the builtin steps)
Henry: If we're going to define a prefix that we'll use in the canonical declare-steps for all the builtins, should we make that facility available to users?
Murray: What I'm hearing is that this isn't a facility of the specification, it's just an extra thing that some tools might use but not implementations.
Henry: It is interesting to note
that in 7.1.1, it says "the attribute-name is a QName
... What it does not say is "it is a dynamic error if the attribute name is not a QName".
Norm: Yeah, it probably should
Henry: We could sure simplify the spec by providing types and enforcing them.
Norm: We could do that, what bothers me is that it wouldn't check xpath expressions and match patterns.
Henry: I have regular expressions
that could do the job.
... at least without false negatives.
Alex: We could just special-case
... I'm just not sure that this is really the way we should go. It's really easy for the language of the step to say the type of the thing is string but it's an XPath expression and must be valid.
... My point is that the type stuff is valuable, but not for checking additional constraints like XPath
... I'm not sure we want to special case that.
Henry: There are three possibilities: 1. do nothing; 2. add type and say it must be XSD simple type and must be enforced; 3. add an advisory type attribute (perhaps as a documentation convention)
Alex: I'd be interested in 2, but I wouldn't want it to be required.
Henry: Not required, but it would
have to be checked.
... So what's changed is we started saying it was documentation now we're saying that you can check it.
Norm: I come back to the fact that what we started with was select vs. match and what we've just proposed *doesn't* address that case.
Richard: Checking against a schema type when you have to check them *anyway* in order to implement them, seems redundant.
Henry: I don't see a problem there. You can produce a schema document that has two types for match patterns and expressions that are unconstrained subtypes of xs:string.
Richard: Schema validation is only optional in the whole implementation, I certainly don't want to sneak it in just to deal with this.
Henry: I think the strongest position anyone has taken so far is "you may" check against these.
Richard: I wouldn't want people to be able to declare a component that took a restriction of XPath using regex.
Alex: Implementors can do that if
... If the original motivation was distinguishing types of XPath expressions, I don't think we've come anywhere near that.
Norm: I'm tempted to do this with an XML comment!
Henry: I think it's a huge value add if the tableau says "<p:option name="attribute-name" type='xs:QName' required='true'/>"
Alex: I agree, but I think we need to take this further.
Henry: I can live with that, I
think the interesting question is, do we say that it's got to
be a QName?
... that references a type declared in W3C XML Schema, or, ...
... is it impl. defined how definitions for these types are found? Or are you not allowed?
Alex: If we're going to put a type attribute there, why didn't you use it on your own steps? And so we'd have to pick a library.
Alex: The obvious candidate is simple types. We'd have to agree that that makes sense. I don't see a proliferation of other data type libraries.
Norm: There's DTLL from DSDL.
Straw poll: Should we persue some sort of type attribute for options or parameters?
Henry: String, boolean, and integer exhaust the types we'd need to do the builtins.
Alex: There are a handful of token values too.
Henry: If we said the declarations in section 7 must be enforced, it doesn't require a processor to implement XML Schema, just a handful of types that they have to implement anyway.
Results: Yes: 3; No: 1; Abstain: 4; Concur: 2
Murray: Couldn't we declare the
names of the types we're using and provide a URI to the
definition. Then it's up to the processor to decide whatever
needs to be done.
... That way a processor could decide that it doesn't care, or it can go do all the type checking.
Henry: I think that's helpful; the ones that we need in order to do a reasonable job on our on types don't have to be declared, they're already declared as used.
Scribe isn't sure he captured that.
<scribe> ACTION: Henry to make a concrete proposal in email [recorded in http://www.w3.org/2007/08/23-xproc-minutes.html#action01]
Richard: Whatever we decide, it should say somewhere that it's a dynamic error for steps to be given options of incorrect types.
Norm: Yes, we could do that globally.
Mohamed: Is it possible to have the comments next to each option for the moment?
Henry: Let's settle the question first.
Richard: For the case of QNames, we have our own namespace binding mechanism. Does XML schema say that they have to be the in-scope namespaces?
Henry: Yes, it says that.
Richard: That's not what we do.
Some further discussion of what this means
<p:option name="attribute-name" value="x:foo" xmlns:x="">
Henry: The question that arises is, does this type attribute apply to values computed by a select.
Some more discussion
Henry: I didn't realize that this
applied to value attributes, only select.
... I think it's just wrong to apply it to value. The value of 'value' is not a QName in this case.
Richard: The Schema spec says that the mapping must be in scope in the "context in which the value is used". And it's not clear how abstract that's meant to be.
Henry: It meant the element.
Alex: In this case, we have a
special kind of context for in-scope namespaces and I think we
should be consistent.
... I don't think we should have one way to interpret it for value and one for select.
Henry: I disagree.
Norm: Henry, do you think value='x:foo' and select="'x:foo'"' should be different?
Henry: Yes, that's the implication.
Norm: I suggest we take the rest of this back to email
Henry: If this is the case, my inclination is to say we shouldn't be calling these things QNames.
Norm: They may not be xs:QNames, but they're QNames.