- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 12 Dec 2007 14:01:39 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2ir3368ks.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/11/29-minutes
Sorry for the delay...
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 93, 29 Nov 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Paul, Henry, Rui, Richard, Mohamed, Andrew
Regrets
Alex, Murray
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 6 December 2007?
4. Comment #68 Comments from the XSL WG
5. Comment #69 should default ports be named
6. Comment #70 circular imports
7. Comment #71 http-request/etc. and URI encoded references
8. Comment #72 name attributes and fragment identifiers
9. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/11/29-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/11/15-minutes
Accepted.
Next meeting: telcon 6 December 2007?
Norm, let's meet next on 13 December isntead
Mohamed gives likely regrets for 13 December
Comment #68 Comments from the XSL WG
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C068
1. Resolved
2. Why all these steps?
Norm: I don't really have any sympathy for their position
Some answers: pipelines are easier to understand, streaming is likely to
be easier in some cases, ...
Henry: I think it's worth emphasizing that we anticipate that a
significant user community will be processing very large inputs through
very simple pipeliens and having to pay the cost of an XSLT runtime for
this is not very attractive
Norm: What do we say about the fact that we don't guarantee streamabilty
Henry: No, that's a QoI issue.
Norm: Ok, let's start there. Anyone want to add anything else?
Richard: The question about streaming is more specific.
Henry: It's very easy to detect a very small subset that's streamable, but
that subset covers a lot of use cases.
Richard: If you want to do some analysis, you can stream up to a point and
then build a tree which is less practical for XSLT
3. Parallel executions
Norm: I don't understand the comment.
Henry: I don't understand the third sentence.
... The classic case is a document styled with a stylesheet generated from
the same document. What's the problem?
Richard: I think maybe they just don't understand that we're saying you
have to make it work.
Norm: I think we should ask them to clarify.
Richard: The statement in the spec about "the order determined by the
connections" might be being taken too strong.
Henry: Something like, "in an order consistent with the connections"...
4. resolved
5. resolved.
6. resolved
<scribe> ACTION: Norm to reply [recorded in
http://www.w3.org/2007/11/29-xproc-minutes.html#action01[7]]
Comment #69 should default ports be named
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C069
Agreed: we'll give them unreferencable names
Comment #70 circular imports
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C070
Mohamed: I don't find any context where it would be confusing
Norm: It's not possible on pipelines anymore, it's only on other compound
steps
Richard: It's only the defaulted output ports of subpipelines. The only
reason for allowing them is to save people from making up names in simple,
linear pipelines.
... I think if they want to make reference to names out-of-order then they
should have to declare the port.
Mohamed: I'm ok with that. It'll be defaulted on both ends usually.
Henry: I think his message has been overtaken.
... Our discussion at the plenary clarified the issues a lot and moved us
forward.
... It would be good to get Alex's input. But we could talk about the last
three paragraphs.
Richard: The main point of Henry's message is that there's a proof that it
can be made to work.
... Henry's description is based on the approach that I'm taking which
does several passes.
Norm: I suggest we leave this open for a week to get Alex's input.
Henry: We need to say something about reentrancy as well as circularity
Richard: I don't think the term reentrant is generally understood to mean
what you mean here
... It's the diamond pattern: a imports b and c and b and c both import d
Norm: Yeah, the editor will have to figure out how to express that. Poor
sod.
Comment #71 http-request/etc. and URI encoded references
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C071
Norm: I think they're all LEIRIs and that's all we need to say
Henry: I think we should say that.
Norm: I agree. I'll see if that satisfies Alex.
Comment #72 name attributes and fragment identifiers
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C072
Norm: There was some pushback on the places where I put names, so I think
we probably need to discuss fragids and MIME types again
Ricahrd: I think there's value in having the names independent of the
fragid question, it improves error reporting.
<ht> Here's the only place I can find which discusses fragids:
http://www.w3.org/XML/XProc/2007/08/09-minutes.html#item05[12]
Henry: If we do this, then we have to address the question of uniqueness.
Do we make these things unique like their sisters and cousins or not?
... We have a general purpose mechanism for naming bits of XML syntax,
it's xml:id.
... I'd like to set this aside from the question of our own XPointer
scheme for a moment.
... It feels a little bit like we have a hammer in our hands so everything
looks like a nail.
... The most bizarre aspect of this is the fact that there's no discussion
of the name attribute in some of those places, like p:declare-step.
... If you give a pipeline library a name attribute, people are going to
think you can refer to it by name.
... We don't really expect that to mean anything.
... Users are going to think there's some deep complexity there but there
isn't, there's barely any there there.
Richard: You took the names out, Norm, but they still get names like !3
Norm: Yes, but if we undo the fragid decision...
Richard: Like I said, I use the names to report errors and I use the !
names if they don't have any.
Henry: So what's the question?
Richard: Well, there's no doubt that all steps have to have names because
they have ports.
... So it's the things that don't have ports: pipeline-library, catch,
when, otherwise, ...
Henry: My compromise position is, I'm a little nervous, but I could live
with putting names on the schizophrenic contstructs.
Richard: It's the things inside try and inside choose except group.
Henry: Like I said, I could live with names there; it doesn't really
conflict with the object model.
... It's declare-step that I think shouldn't have one.
Richard: That's funny, I was going to go the other way. It seems that
declare-step should be like pipeline in this regard.
Norm: We do have this weirdness with namespace and name in pipeline
library.
Henry: I agree, pipeline and declare-step should have the same naming
structure.
Norm: Name doesn't work then because they're NCNames.
Richard: Why would you ever want to have a single pipeline library taht
declare steps in separate namespaces?
Norm: Because you aggregated them after you wrote them over time; I don't
see how the library should have a bearing on the names.
Richard: Do we allow any steps to be in no namespace.
Norm: Yes, though it's not clear that we meant it to be that way.
<MoZ> no namespace is impossible because of ignorable-prefix
Norm: So where are we?
Henry: I'm prepared to float the following pair of changes:
<MoZ> <foo:step xmlns:foo="">...</foo:step>
Henry: Reinstate optional names on when/otherwise/catch and remove name
from pipeline and namespace from pipeline-library
Norm: You can't remove name from pipeline, that's how the steps refer to
its ports
Henry: No, they use the local-name of the type attribute
Norm: Uhm. My initial reaction is "eew" but maybe I need to think about it
some more.
Henry: Having to write name="foo" type="my:foo" is just hopelessly
confusing.
Richard: The reason that pipeline is like this is because if its usual
schizophrenia
... You're allowed to have an unnamed pipeline at the moment.
... And an untyped one.
Scribe lost Richard's thread
Henry: We'll never see names and types that are different
Norm: I don't agree, I might name all my pipelines 'main' irrespective of
their type
Henry: So what I said before with a small modification:
1. Remove name from declare-step and pipeline-library
2. Add name to when/otherwise/catch
3. Remove namespace from pipeline-library
4. Remvoe the magic about name/namespace for defaulted types in a pipeline
library
5. Make type required on a pipeline in a pipeline library
Norm: So the editor should give that a wack?
Agreed.
Any other business?
None.
Adjourned
Summary of Action Items
[NEW] ACTION: Norm to reply [recorded in
http://www.w3.org/2007/11/29-xproc-minutes.html#action01[13]]
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/11/29-agenda
[3] http://www.w3.org/2007/11/29-xproc-irc
[7] http://www.w3.org/2007/11/29-xproc-minutes.html#action01
[12] http://www.w3.org/XML/XProc/2007/08/09-minutes.html#item05
[13] http://www.w3.org/2007/11/29-xproc-minutes.html#action01
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[14] version 1.128 (CVS
log[15])
$Date: 2007/12/12 19:00:35 $
Received on Wednesday, 12 December 2007 19:01:57 UTC