- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 15 Mar 2007 16:28:26 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87zm6eqmj9.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/03/15-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 59, 15 Mar 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Michael, Paul, Norm, Alessandro, Rui, Mohamed, Henry, Alex,
Richard, Andrew
Regrets
Murray
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 22 Mar 2007
4. Review of the 28 Feb 2007 Editor's draft
5. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/03/15-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/03/08-minutes.html
Accepted.
Next meeting: telcon 22 Mar 2007
Regrets from Mohamed
Review of the 28 Feb 2007 Editor's draft
-> 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 his discussion is postponed
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?
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.
Any other business?
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.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/03/15-agenda.html
[3] http://www.w3.org/2007/03/15-xproc-irc
[8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[9] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[8] version 1.128 (CVS
log[9])
$Date: 2007/03/15 20:27:33 $
Received on Thursday, 15 March 2007 20:28:53 UTC