- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 23 Aug 2007 12:12:53 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2tzqqz0u2.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/23-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 81, 23 Aug 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Paul, Mohamed, Rui, Alessandro, Andrew, Murray, Henry,
Richard, Alex
Regrets
None
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 30 August 2007
4. Comments on the new draft
5. Advisory type attribute on p:option
6. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/08/23-agenda
Amended with item 3, a advisory type attribute for p:option
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/08/16-minutes
Accepted.
Next meeting: telcon 30 August 2007
Murray and Alessandro give regrets for 30 Aug
Comments on the new draft
-> http://www.w3.org/XML/XProc/docs/langspec.html
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 that.
... 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.
Advisory type attribute on p:option
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.
Norm: ok
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 anywhere.
... 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 sense.
... 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 value"
... 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 XPaths
... 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 they want
... 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.
<MoZ> DTLL
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[7]]
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="">
<p:namespaces xmlns:x="..."/>
</p:option>
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.
Any other business?
None heard
Adjourned.
Summary of Action Items
[NEW] ACTION: Henry to make a concrete proposal in email [recorded in
http://www.w3.org/2007/08/23-xproc-minutes.html#action01[8]]
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/08/23-agenda
[3] http://www.w3.org/2007/08/23-xproc-irc
[7] http://www.w3.org/2007/08/23-xproc-minutes.html#action01
[8] http://www.w3.org/2007/08/23-xproc-minutes.html#action01
[9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[10] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[9] version 1.128 (CVS
log[10])
$Date: 2007/08/23 16:10:12 $
Received on Thursday, 23 August 2007 16:11:40 UTC