See also: IRC log
http://www.w3.org/XML/XProc/2007/11/01-agenda
Accepted as distributed
http://www.w3.org/XML/XProc/2007/10/25-minutes.html
Accepted as distributed
F2F in Cambridge MA next Thur and Friday: Norm, Henry, Paul, Alex, Michael (in part)
HST: We will try to announce some summary of discussion and decision making times, for those who are dialing in
Next telcon: 15 November, usual timing
Regrets: Michael
No changes to published list
http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C029
RT: At the end of the last
meeting I was leaning towards requiring declarations for
p:pipeline
... They are short, don't require any bindings
... I think we all rejected the extreme interpretation of the
status quo which would require arbitrary recursive
analysis
HST: RT and I discussed this after the call
last week, and developed a possible alternative: use syntax to distinguish
simple pipelines which would get defaulted input/output declarations from
complex ones which would not. The distinction might be made with two element
types, or an attribute, or . . .
... In the absence of email preparation, let's move on
AV: Please do send an example, but yes, let's move on
<scribe> ACTION: HST to send an example of a 'new syntax' resolution to issue 29 to the list [recorded in http://www.w3.org/2007/11/01-xproc-minutes.html#action01]
http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C018
RT: Don't we have approximate consensus on this, action A-87-03 refers
http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C013
HST: First, let's look at comment 3, section 5.7.3 option 2
http://www.w3.org/XML/XProc/docs/langspec.html#opt-param-bindings
RT: I think MK has misunderstood
it
... The prefixes whose bindings are in question are those in
the result of a 'select' XPath, not in the 'select' XPath
itself
HST: The problem arises because there is no example to hand
AM: I think we have to clarify with an example and with better text, what the purpose of 'default namespace bindings' actually is at this point
RT: There is an example further down
HST: We need a simpler example earlier
RT: Aha, we should be looking at the first numbered list -- OK, yes, I see the problem
HST: Enough here to guide the editor, let's leave it with him
<scribe> ACTION: NW to rewrite 5.7.3 by adding a simple 'select=' example alongside the 'match=' one at the beginning, and trying to clarify what the default namespace binding is for early on [recorded in http://www.w3.org/2007/11/01-xproc-minutes.html#action02]
HST: Moving on to comment 4, a clarification
http://www.w3.org/XML/XProc/docs/langspec.html#p.document
AM: p:load is a step, p:document
is not
... p:document leaves it implementation-defined whether we
validate or not
HST: No, it says you must not validate
AM: I'm surprised that is there. . .
RT: What does it mean to say 'must not validate' ? 'Must not fail for validity errors' I could understand
HST: I think we're looking at the result of Norm trying to respond to MK's comment here. . .
RT: I think this needs to change
to clarify that p:document doesn't fail because of a validity
error
... I think we should follow XSLT here and require that the
external subset be read
... so that all entities are expanded
HST: Do we need to be more explicit about any other processor-dependent options?
AM: I would be sorry to disallow the possibility of a secure environment in which all input of any kind to a pipeline had to be valid
RT: I guess we need to discuss
this at the f2f
... I think AM's point should be an 'at user option' feature. .
.
HST: OK, done until the f2f
... I think wrt MK's second point, NW's change in the 3 Oct.
draft is sufficient
HST:
Moving on to comment 6
... This is subsumed by issue http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C070
... Issue 13 Comment 6 and Issue 70 should be responded to
jointly
RT: The idea is to do things much more cheaply than would be the case if XSLT or XQuery were used
HST: Yes, determines whether you get an efficient implementation without waiting for an XSLT implementation which detects streamability
RT: I've suggested in the past
that we use XSLT stylesheets to provide exemplary
implementations of the steps like these
... removing any ambiguity as to how they work
HST: Interesting idea -- volunteers?
<alexmilowski> Richard suggested it...
<alexmilowski> :)
RT: There may be problems in the details
HST: We'll leave that for now, as a start on subsequent discussion of issue 70
RT: Let's not get bogged down in details of individual steps
HST: Moving on to comment 9, on p:load
http://www.w3.org/XML/XProc/docs/langspec.html#c.load
RT: What is meant by 'namespace
aware DTD validation'?
... assume it means namespace-aware parsing
HST: I think, by contrast with the reference to Namespace Well-formed for p:document, this means that if validate='true', then we require Namespace Validity
RT: Right, e.g. IDs must be NCNames
<scribe> ACTION: NW to clarify by adding reference to Namespace Validity to the description of p:load with validate='true' [recorded in http://www.w3.org/2007/11/01-xproc-minutes.html#action03]