See also: IRC log
Date: 15 Mar 2007
Meeting number: 59, T-minus 33 weeks
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
heh
-> http://www.w3.org/XML/XProc/2007/03/15-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/03/08-minutes.html
Accepted.
Regrets from Mohamed
-> http://www.w3.org/XML/XProc/docs/ED-xproc-20070228/
-> http://www.w3.org/XML/XProc/docs/langspec.html#input-output
Alex: I'm concerned about parameters being available. We have in-scope parameters and importing parameters and no concept of the delta.
Norm revisits the rationale.
Alex suffers telecommunications issues and postpones his discussion
Henry: I've been working on DTDs
and Schemas and so I've found lots of details.
... I'm still concerned about the question of step naming. It's
irritating that because pipelines may have QNames for names
that the pipe element has to have a QName rather than an NCName
for its step attribute.
... The 99.999% case will be than an NCName will do.
... And there can never be more than one pipeline in scope.
Norm wonders why it matters more to Henry than XSLT template names or modes.
Henry: Because they were invented
at the same time as XSLT. XSLT got to say that the
interpretation of QNames was different for mode and template
names.
... So at the very least, it seems like calling the QNames but
having them follow the old XSLT rules not the Schema rules is a
little bit unhelpful.
... Especially since it's a corner case of the extreme sort.
I'm not going to lie down in the road, but it seems
tacky.
... At the very least, more prose is needed in 5.7
Norm: Let's explore a little bit.
Henry: The schema union type of NCName|QName does admit to the right semantics and syntax.
Some discussion of the alternatives
Henry: What if we said that
pipelines like all other steps were named with NCNames.
... And pipeline libraries had a namespace.
... Then you could refer to a pipeline from the outside with a
QName but with an NCName from inside.
... The only substantive change is that it requires all the
pipelines defined in a library to be in the same namespace.
Norm: Uhm, it seems a little arbitrary, but it does solve the problem.
Henry: It does seem every so slightly odd to define pipelines in different namespaces in the same library.
Norm: Does anyone else have a feeling about this proposal?
unmute alex
MSM, we lost you
Proposal: We'll try Henry's proposal: Names of steps are NCNames, pipeline-libraries have a target namespace, all pipelines in that library are in that namespace. Therefore, you can refer to them by QName from outside and NCName from inside.
Accepted.
Michael: I've been struggle to
keep up in the technical discussion, but not necessarily
succeeding very well.
... I've exploited that fact by reading them as a sort of
stranger.
... The biggest question I have when I read the spec is why are
we doing this two-level specification where we have an
abstraction and an XML syntax.
... To do that, you need a coherent story about how these two
abstractions map to each other.
... As far as I can tell, if you try to read the document
solely at the abstraction level, we don't say nearly
enough.
... You don't say how our abstractions relate to each other,
which ones are legal or not, how they're different from blocks
of wood.
... In fact, we rely on the XML syntax for many of these
things.
... It would be better to just treat all the extra stuff you
need as additional information associated with XML
elements.
... I think we thought it was a good idea at the time, but it
has turned out not to be. Doing it well would be too
expensive.
Norm agrees wholeheartedly.
Richard: I don't agree. The conceptual sections may not have had anything about the ordering of steps. But it could have done.
Norm: Indeed, it could have been done that way, but it would be a lot of work. Are you in favor of improving the conceptual model.
<MSM> [They could indeed have done. But when you look at the abstraction level as a thing in itself, the question becomes "why are they doing it this way?" And imposing an order for the purpose of calculating defaults seems like an unmotivated design feature.]
Henry: It won't surprise you to
know that I have a residual preference for keeping the
conceptual model separate, but I also don't think that as thing
stand the difference is doing enough work to justify arguing
against the editor.
... Looking at XSLT 1.0 as a model, it quite cheerfully talks
about templates and template rules independent of the elements,
but it doesn't make a big deal about the differenc.e
... I think it's easier to read because it doesn't attempt to
go as far as Michael suggests.
<MSM> [? I think XSLT speaks about templates only in ways compatible with the statement "a template is an XML element"]
Henry: I think it would be confusing to try to talk about only the elements.
Michael: Two things: One, the way
of talking about things that XSLT 1.0 uses seems about right.
With that, I'm in full agreement. But second, Henry believes
they're talking about things that are different than the XML
elements and I don't think that's the case.
... Perhaps I could be persuaded to believe that XSLT 1.0
postulates a level of abstraction distinct from the elements,
but I don't think it does.
<alexmilowski> BTW, I absolutely 110% disagree with Henry's proposal.
<alexmilowski> Stupid cell phone...
Micheal: You don't need to make a
big thing of it, and I think the easiest way to do that is to
say that it's an element, just like a "for" loop in C is a
sequence of characters.
... There are lots of unanswered questions in the abstraction
that are trivially answered by the XML syntax.
<ht> HST would rather be silent on the relationship, but I'm happy to be ruled by what the editor finds congenial and/or we find out what XSLT actually does in this regard
Norm: I don't hear anyone objecting to the editor attempting to merge the two sections.
Richard: "A template rule is
specified with the xsl:template element..." In fact, they have
three different things: they have the template rule, the
xsl:template, and the template itself.
... There's something abstract here.
No objections. The Editor will try.
Norm: Alex, would you like to revisit the QName/NCName step issue.
Alex: A p:import can import a
single pipeline that isn't in a library.
... That's a feature that we'd lose if we did this change.
Norm: Indeed, that is the case.
Alex: I think QNames are really simple.
Norm recounts Henry's objection vis-a-vis interpretation of unprefixed names.
Alex: Yes, but some people think that Schema got that wrong.
MSM: Does the definition of QName
specify where the namespace bindings come from? I don't think
it does.
... My instincts tend to be with Henry here, but I want to
understand the technical issue.
... The Namespace spec says that the way that unqualified
element and attribute names are resolved is different. XSLT 1.0
goes further. And XSLT 2.0 goes even further with respect to
funcction names.
... I think we could say that interpreting step names it works
this way, and I don't think that's incompatible with the way
that QName is defined.
... And we could write a last call comment on the datatypes
spec if we do find that.
... And if it isn't clear, we could comment on that too.
Henry: With respect to the
datatypes spec, I think it is clear that the in-scope
namespaces in the infoset is referred to.
... I think it's very clear that it is an error to have an
unqualified name of type QName in an instance document if
there's no binding for the default namespace.
... We can certainly write our own rules. It's the fact that
99.999% of the time NCNames are all that's needed.
... I'm not at all clear that the case Alex mentioned should be
enough to change our position.
<MSM> [W.r.t writing our own rules - I think the point of disagreement here may be just whether doing so means we ought not to use the QName type, or must use a union of NCName and QName.]
There's no way to predict if importing pipelines or pipeline-libraries will be more common.
Henry: I still like the resolution above and what it amounts to when importing single pipelines is that you risk a name conflict.
Norm: We did resolve this. Is there anyone that on the basis of Alex's observations wishes we'd resolved it differently?
No one heard.
Norm: Has anyone looked at the draft that includes options?
Henry: Yes, a while ago. It looks good on the face of it, but I haven't looked at it line-by-line.
Mohamed: I looked at it.
... I found the way that it's explained reflects the
discussion, so I think we should keep it.
Norm: Anyone want to reject the options draft as the status quo.
Accepted.
Norm: Did anyone see anything in the 28 Feb draft that they'd object to seeing in the next public draft.
Mohamed: I'm concerned about the
consistency of viewport-source, iteration-source, and
xpath-source.
... I don't find the explanation about why some are one way and
some are not very clear.
... I think sequences are just not very clear at a deep
level.
<MSM> [Checking the current Datatypes spec diff w/1.0, I don't see any mention of [in-scope namespaces] in the section on QName. There's a note that says that the mapping requires a namespace declaration to be in scope for the mapping to work, but that doesn't seem to determine the treatement of unqualified names. (It appears to contradict the normal assumption that if there is no default ns declaration, the QName mapping is well defined.)]
Norm: I'll publish a new draft this week that I'd like to vote on for making public at the next telcon.
<alexmilowski> [That seems more consistent with XSLT vs XQuery ]
Norm: So next week, I'll see if anyone has any show-stoppers and then we'll look at the component list.
No one objects to that plan.
Henry: I would like to see the various schemas appearing in the draft.
<ht> Michael, you are right, and I was wrong -- only Schema Representation Constraint: QName Interpretation in Part 1 is unequivocal, and _it_ as written only applies to attrs of type QName (not elts), and _could_ be claimed to only apply to attrs in schema docs
Ok.
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/at ti/at it/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: MSM, PGrosso, Norm, rlopes, MoZ, Alessandro, Ht, Alex_Milows, richard, AndrewF Present: Michael Paul Norm Alessandro Rui Mohamed Henry Alex Richard Andrew Regrets: Murray Agenda: http://www.w3.org/XML/XProc/2007/03/15-agenda.html Found Date: 15 Mar 2007 Guessing minutes URL: http://www.w3.org/2007/03/15-xproc-minutes.html People with action items:[End of scribe.perl diagnostic output]