See also: IRC log
Date: 10 January 2008
<scribe> Meeting: 97
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2008/01/10-agenda
Accepted
-> http://www.w3.org/XML/XProc/2008/01/03-minutes
Accepted
Norm: Anyone think we want to try to do that before the Tech Plenary? (Oct in Mandelieu)
Henry: I can imagine that we are
sufficiently finished with XProc in a few months that it will
be time to turn our attention to our other task.
... Sitting around a table would be the best way to start.
Norm wonders about Balisage...
Norm: Let's wait and see
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html
Comment 21: XProc localization
Norm outlines his message about making p:error take its description from an input port
Henry: This resonates with
something I encountered when trying to simplify the early
example pipelines.
... Sometimes you'd like an alternative between an input port
and an option.
... For example, I'd like to be able to specify the XSLT
stylesheet by way of an option instead of on an input
port.
... It's just laziness, but the idea of having an option and a
port in a trading relationship seems very natural
... The alternative is that folks won't provide descriptions
for errors.
... Do we want to consider adding this feature?
Richard: Can't you do it with a select and an expression?
Norm: No, because it gets turned
into a string and the markup is thrown away.
... I guess my reaction is, gosh that's a nice feature but
aren't we done adding features?
Henry: It's not a feature it's a design pattern.
Richard: It seems to me that it's a bit excessive for what it does.
Support does not seem to be rising for the coocurrence constraint idea.
Norm: Do we want to make the
description of p:error an input port?
... I observe that it does require the user to make up some
random document element for the message.
Richard: What about structured content?
Norm: No, way too much feature
for now. We could remove the restrction to strings, but that
didn't get support alst time it came up.
... Straw poll: Input or option?
Input wins with unanimity.
<scribe> ACTION: Norm to change the spec to make error descriptions come from an input port on p:error [recorded in http://www.w3.org/2008/01/10-xproc-minutes.html#action01]
Some discussion of why we might do this
Richard: I'm inclined to keep
them together.
... I think it's simpler for readers to ahve it all in one
document.
Paul: The biggest advantage as
far as I'm concerned is that you could advance different parts
to PER, for example, independently.
... For example, you can tell folks we haven't fiddled the
language, we've just changed the steps.
Henry made apoint earlier about the fact that breaking it into pieces doesn't necessarily make it into separate RECs
Paul: I don't think it makes sense to do unless we make different RECs.
Norm: The editor doesn't feel strongly one way or the other, for what it's worth.
Henry: I think Paul's argument has value, but I don't feel that strongly either.
Some discussion of adding steps in the future
Henry: At worst, we can always
change our minds later.
... At V1.1 time, for example.
The chair doesn't hear consensus for splitting the document at this time.
Norm summarizes how we got where we are
Richard: One advantage to inventing your own namespace is that it designates the owner of the info.
Norm: We could mandate, suggest, or leave that problem to implementors
Alex: Why?
Henry: Because it's just not
clear and is contradictory in the spec.
... The core of my problem is that we invite people to put an
element between two steps but we say it musn't change the flow.
That's just bizarre.
Some discussion of the extent to which deleting them is appropriate.
Norm: I guess the position I've come to is that ignored namespaces introduce some complexity without much benefit over having a single element for this purpose.
Alex: What about making them top-level?
Henry: Yes, excpet that the spec
tries to do that and it gets confusing.
... Instead of putting it in subpipline, couldn't we put it in
the prolog?
Richard: Does having a p:appinfo solve the placement problem?
Some discussion, basically yes.
Alex: I'm partial to the ignored namespace thing, but I don't mind having an appinfo, as long as we don't call it "appinfo".
Straw poll: keep ignored namespaces,or abandon them in favor of some element to be named later.
Results: 6 for new element, 1 for ignored namespaces, and 1 abstention.
Name the new element...
pipedata
userdata
<MoZ> pipeinfo
pragma
Results: pipedata: 3, userdata: 2, pipeinfo: 4, pragma: 3
The winner is p:pipeinfo.
Norm: I'm inclined to say not.
Alex: I'm inclined to allow them so that you don't have to jump into a new syntax just to provide two input documents.
Richard: Because this is the simple case, I was expecting it to be used on the command line and that's possibly going to make the output syntax different.
<MoZ> +1 with Richard on output
Richard: I was planning to
implement sequences as directories, that means I'll always get
a directory even when there's only a single file.
... I can work around it, but it seems a bit yucky.
Some discussion of the various possibilities
Alex: If I put an XSLT inside a pipeline, I shouldn't have to fiddle the syntax depending on whether or not a sequence is produced.
Straw poll: sequence or no sequence?
<ht> I note that saxon 8 just concatenates multiple unnamed result-documents on stdout
Results: sequence: 2, no sequence: 4, abstain: 2
Henry: What about sequence on input, no sequence on output?
Alex: I'm not going to lie down in the road over sequences.
Alessandro: I think we shouldn't let constraints on the command line system influence how we design our language.
Richard: I'd agree, except that
we're only discussing the abbreviated form. And that does seem
to me to have a more direct connection to useability on the
command line.
... It's there for simple cases.
Norm: Is there anyone who can't live with no sequences on input or output
None heard.
None.
Henry: I'd like to encourage the wG to identify any issues between here and last call.
Some discussion of circular imports in pending mail.
Adjourned.
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/dot his/do this/ Succeeded: s/ifno/info/ Succeeded: s/n,./n./ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, Ht, PGrosso, avernet, alexmilowski, richard, Andrew, MoZ Present: Norm Henry Paul Alessandro Alex Richard Andrew Regrets: Murray Agenda: http://www.w3.org/XML/XProc/2008/01/10-agenda Found Date: 10 Jan 2008 Guessing minutes URL: http://www.w3.org/2008/01/10-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]