See also: IRC log
-> http://www.w3.org/XML/XProc/2006/05/11-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/05/04-minutes.html
Accepted.
Already regrets from: Andrew, Michael, Henry
Please register: http://www.w3.org/2002/09/wbs/38398/XProcFTF2/
Local arrangements: http://www.w3.org/XML/XProc/2006/08/02-04-f2f.html
Norm hopes we can nail down the transport next week.
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3089
MoZ: are you trying to dial in and not getting through the bridge?
Norm: Three possibilities, 1) use someone else's streaming subset, 2) invent our own, 3) use full XPath and leave it as a QoI issue
Alex: Although I use a streaming subset, I think that's an optimization. I think we shouldn't have a subset.
Norm: I can find off-the-shelf
full XPath 1.0 implementations, so I think that answer makes it
easiest to get started
... Is there anyone that thinks we need to define a subset?
Henry: I'm uncomfortable, but I'm willing to leave it for CR.
Norm: That works for me.
Richard: Do we have a good idea of what circumstances these XPaths are used in
Norm: Off the top of my head, we've got: conditionals, peepholing
Richard: Also the "replacement"
component
... It's possible that that's a component by itself.
Norm: so those wouldn't have to be the same.
Richard: I think I'm happy for it to be full XPath 1.0 and I can detect some streamable queries.
Proposal: We will use XPath 1.0 in our language
Alessandro: I think it will be interesting to have XPath 1.0 vs XPath 2.0 question
Alessandro: At least in the environment I am working in, off-the-shelf 2.0 implementations are easy to come by.
Norm: Do you have a use case in mind for pipeline conditionals?
Alessandro: Not off the top of my head
Alex: We could declare what version of XPath the pipeline uses and implementations can reject pipelines they can't support.
Richard: Isn't it the case that
if you have XPath 2.0, you have to worry about whether the data
has schema type and so on.
... I know that there are XSLT 2.0 implementations that don't
support the schema stuff and can give different answers.
... If we introduce XPath 2.0 are we introducing new levels of
conformance.
Norm: Yes, I think they
would.
... This seems useful and interesting, but not necessary.
Norm observes, in response to Richard, that having XPath 2.0 would mean that the pipeline engine would have to be able to import schemas
Alessandro: In environments where 2.0 is available, requiring XPath 1.0 seems like a burden
Norm prefers a single choice for interoperability
Alex: By the time we become a
recommendation, we have to have a cohesive store around XSLT
2.0, XPath 2.0, XQuery, etc.
... I don't think we can push that to V.next, we need to come
out with a recommendation that works well with those
technologies.
Norm: Wow. Ok.
Norm worries that dealing with those things in 1.0 makes our goal of finishing this year hopeless.
Alessandro: I agree that there's
complexity, but I think we should try just a little bit harder
to try to accommodate schemas and XPath 2.0
... It might be the case that we come to the conclusion that we
can't do it in 1.0
Murray: I would tend to agree
with Norm, let's do something we can accomplish in the
timeframe we set out, even if it isn't' as grand and robust and
wonderful as we might achieve in the fullness of time.
... We can move onto the next stage afterwards.
Norm: Can Alex/Alessandro make some proposals to see if you can convince us that using schemas, XPath 2.0, etc. is achievable in our timeframe?
Alessandro: yes
Alex: yes
Proposal: We will assume full XPath, not a streaming subset, in the language (unless and until we get pushback from implementors)
Accepted.
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3198
We've already made a decision about this, this issue is just for the future
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3199
We don't really have any clear ideas about exactly how these things fit together yet
Norm reviews Richard's ideas that started this
Richard: Fundamentally, it must
be possible to get some output into a parameter.
... The simplest way to define a parameter is to give a literal
value.
... The next way up would be to give an XPath and the output of
some other component to apply it to. It would evaluate the
expression and the result would be the value of the
variable
... So the temporary file component could generate a document
and the XPath expression could be "."
... This means that all these things are connected by
plumbing.
... Other people have mentioned at various times mechanisms for
having variables that are in scope, etc. But I think the simple
method is a good starting point.
Norm: I had in mind setting
variables in general being specified with XPaths (so that
pipeline params could be composed from command line params
(for example) and others.
... I was thinking of evaluating them all with an empty
document node as the context.
... Extending that to allow them to specify an input document
makes sense.
... Is that sufficient?
Henry: It ought to be possible in a pipeline definition to say that the value of some step parameter is referred to at the pipeline level
Scribe isn't sure that he recorded Henry correctly
Norm: Parameters could have two attributes: value and select for literal values and XPath expressions
Some discussion about how these things get connected together syntactically.
Richard: I think the 90% case is that variables are constants. It's reasonable for it to be slightly complicated.
<scribe> ACTION: Norm to write up his thoughts on parameters and inputs [recorded in http://www.w3.org/2006/05/11-xproc-minutes.html#action02]
Alex: This is related to the variables action that I have
Richard: It would be nice if this
mechanism was extensible to being able to having different
variables in scope in different parts of the pipeline.
... But it's not immediately clear to me how it is. But maybe
it is.
None.
Adjourned.