- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 09 Aug 2007 12:18:58 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87tzr8hea5.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/09-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 78, 9 Aug 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Alessandro, Mohamed, Andrew, Norm, Alex, Richard
Regrets
Paul, Henry, Michael
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 16 August 2007
4. Comments on the new draft
5. Question of MIME type/fragid
6. Question about anonymous steps or defaulted names.
7. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/08/09-agenda
Reorder items 2 and 3
Mohamed: I'd like to talk about p:pack.
Norm: Ok, we'll make that item 5
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/08/02-minutes
Accepted.
Next meeting: telcon 16 August 2007
Probably regrets from Mohamed
Comments on the new draft
-> http://www.w3.org/XML/XProc/docs/langspec.html
Norm: I think it's pretty good except for the namespace bindings.
Richard: The diffs are pretty amusing.
Mohamed: What happend to err:?
Norm: I took it out for err:errors and err:error because we can use c: for
that.
... Then I remembered error QNames, so I put it back.
... Everyone ok with that?
Seems so.
Question of MIME type/fragid
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0076.html
Norm: Are we going to define one and do we want one?
... Having a MIME type lets us identify pipeline documents; having a
fragid syntax would let us describe how to point to important parts of a
pipeline.
Norm describes his attempt at a fragid syntax.
Richard: We need to get this right before Last Call, right?
Norm: Yeah, I guess so.
Alex: Do we need to have a fragid syntax?
Murray: What would we identify
Norm: We would identify steps, ports, and options.
... We don't have a need, it's a question of whether we want to provide
hooks for others.
Murray: I'm some author outside a group of pipelines; so I might write an
RDF statement that talks about these things; I might create a hypertext
link to one.
... Can I invoke a step this way?
Norm: No
... You could also use it for error messages.
Richard: Seems strange to do this when we don't use them.
Norm: I get the impression that we're leaning towards a MIME type but not
the fragment identifier.
<richard> the xpath xpointer scheme doesnt exist
Murray: I can see the value in being able to refer to steps from the
outside. I'm not sure I get the value in having fragids for the ports.
Norm: So I propose that we define a MIME type, application/xml+xproc, but
not a fragment identifier syntax.
Murray: How hard is it to point to steps?
Norm: Easy, if they have names and the names are unique.
Richard points out that pipelines in a library could easily have steps
with the same names
Alex: There's not a lot of precedent here, lots of recent specs don't have
MIME types.
Richard: I haven't heard any compelling arguments for a fragid syntax.
Norm: So it seems like the consensus is MIME type yes, fragids no.
<MoZ> <p:documentation xml:id="foo" />
Murray: If we think pipelines are going to be popular, which I think we
do, it seems like there will be lots of people who want to talk about
them.
Alex: One rational position is to not require to sprinkle xml:id over
their documents. If you want to point to something, you have to name it.
... Then we can do something like what Norm proposed and provide a
mechanism for pointing to them.
Richard: Though I see that you might want to talk about these things,
without tools, it's not terribly useful to point to them.
Murray: That's a chicken and egg thing, isn't it?
Norm: I'd like to set this aside for a moment and go on to the next item.
Question about anonymous steps or defaulted names.
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0077.html
Norm outlines his message
Murray: I like the idea.
Mohamed: I'm not sure I like the defaulting of inputs to the p:pipeline.
Norm: Yeah, but that's not really the issue here.
Alex muses about the syntax Norm proposed.
Richard: The presence of named ports wouldn't changed the names, would it?
Norm: We could actually use "source" and "result" for manufactured port
names.
<alexmilowski> xyzzy-nn
Murray: Would we have to use the section symbol in the URI?
<MoZ> <p:pipeline>
<MoZ> <p:for-each>
<MoZ> <p:xinclude/>
<MoZ> </p:for-each>
Norm: Yes, that's the price you pay for not having put your own name on
the step.
<MoZ> <p:for-each>
<MoZ> <p:xinclude/>
<MoZ> </p:for-each>
<MoZ> </p:pipeline>
Norm: Is anyone in principle against this proposal?
Mohamed: Yes.
Norm: Why?
Mohamed: It's giving more possibilities for users to not use names.
<alexmilowski> mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
Alex: It'd be nice if we picked a character name that doesn't require URI
encoding.
Norm: Ok, how about "!"
Mohamed: I'm ok with naming steps.
Norm: One of the goals is to remove a concept from the spec, I don't
anything to be anonymous.
Richard: You think you're going to use these in some hypothetical fragment
syntax?
Alex: I like the idea that you can't use the manufactured name in the
syntax.
Richard: We're going to specify that the things have these names. Are
implementations going to have to use them?
Norm: In a running pipeline, you'll never see them.
Richard: So this has no normative effect.
Norm: True, but the spec will still be simpler because it has one less
concept.
<alexmilowski> +1
Norm: I propose that we direct the editor to give this a try and see if we
like it.
Accepted.
Norm: Drat. We won't get through namespaces in 10 minutes, let's return to
MIME type/fragid.
Alex: I'm all for using the manufactured names in a fragid syntax.
Norm: Anyone opposed to having a fragid syntax for steps.
... I propose we direct the editor to give that a whack too.
Accepted.
Mohamed: Take care that we don't overlap with the use of xml:id.
Norm describes the problem
Alex: Have you looked at what XSLT does with xsl:element
Norm: Yes, but that doesn't work for us.
Richard: Suppose you just construct arbitrary strings in options, you
expect those to go through.
Norm: Then you need the union of all the bindings on all the variables
used
Alex: What about the opposite case, where you don't want the bindings from
the document?
... XSLT avoided all this magic
Norm: So the proposal is, the namespace bindings you get on the match
option passed to the delete step are the ones that are in scope for that
p:option. If they don't match up, you lose.
Richard: XSLT gives you a workaround for these cases.
Some discussion of the options
Alex: We could give another attribute on p:delete that could point to an
element on which to find the namespace bindings for this expression.
Richard: There'd be security considerations here, yes?
Alex: I still think "you lose" is the simplest answer.
Norm: Would anyone be uncomfortable wit the "you lose" proposal?
None heard
Any other business?
None.
Adjourned.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/08/09-agenda
[3] http://www.w3.org/2007/08/09-xproc-irc
[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/09 16:16:48 $
Received on Thursday, 9 August 2007 16:19:11 UTC