08:37:37 <RRSAgent> RRSAgent has joined #xproc
08:37:37 <RRSAgent> logging to http://www.w3.org/2012/11/01-xproc-irc
08:37:44 <Zakim> Zakim has joined #xproc
08:37:48 <Norm> zakim, this is xproc
08:37:48 <Zakim> sorry, Norm, I do not see a conference named 'xproc' in progress or scheduled at this time
08:38:09 <Norm> rrsagent, set logs world-visible
08:38:12 <Norm> Meeting: XML Processing Model WG
08:38:12 <Norm> Date: 1 Nov 2012
08:38:12 <Norm> Agenda: http://www.w3.org/XML/XProc/2012/11/01-agenda
08:38:12 <Norm> Meeting: 223
08:38:12 <Norm> Chair: Norm
08:38:12 <Norm> Scribe: Norm
08:38:13 <Norm> ScribeNick: norm
08:49:25 <Norm> Norm has changed the topic to: XProc f2f http://www.w3.org/XML/XProc/2012/11/01-agenda
08:49:30 <jfuller> jfuller has joined #xproc
08:49:59 <Norm> Present: Henry, Norm, Jim
08:50:02 <ht> ht has joined #xproc
08:50:21 <Norm> Topic: Accept this agenda?
08:50:21 <Norm> -> http://www.w3.org/XML/XProc/2012/11/01-agenda
08:52:51 <jfuller> comments
08:52:52 <jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
08:53:03 <jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0006.html
08:53:36 <Norm> Henry: We should try to talk about some design issues: binary data/resource manager; parameters
08:55:44 <Norm> Topic: Accept minutes from the previous meeting?
08:55:44 <Norm> -> http://www.w3.org/XML/XProc/2012/10/18-minutes
08:55:49 <Norm> Accepted.
08:55:58 <Norm> Topic: Next meeting: telcon 15 Nov
08:56:06 <Norm> Accepted.
08:59:03 <Norm> Topic: Parameters
09:00:18 <Norm> -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0014.html
09:15:48 <Norm> Random points of discussion:
09:15:54 <Norm> Where do maps fit in the data model?
09:19:00 <Norm> Having p:with-param that takes a context node and adding a function that can read a serialization of a map and produce a map is probably necessary
09:20:20 <Norm> Henry: We could allow multiple with-params with the same name and that would allow you to have each parameter have its own line.
09:20:56 <ht> <p:with-param name="parameters" pname="foo" select="[xpath expression]"/>
09:22:10 <ht> would be an alternative to
09:24:47 <Norm> Norm wonders if we really need to support the case where a pipeline can have *more than one* set of parameters.
09:25:06 <Norm> ...Ostensibly its for the case where a pipeline has two XSLT steps and need two different sets of parameters.
09:25:23 <ht> <p:with-param name="parameters" select="merge-maps(map((foo,[xpath expression])))"/>
09:25:58 <Norm> We could do this:
09:26:07 <ht> s/foo/'foo'/
09:26:10 <Norm> <p:with-param group="parameters" name="foo" select="[expr]"/>
09:26:54 <Norm> <p:with-param name="foo" select='[expr]'/>
09:27:16 <Norm> Henry: That makes the 'name' of a p:with-param very different from the name on a p:with-option
09:29:19 <Norm> We all agree that V.next will be XDM/XPath 2.0 based
09:31:19 <jfuller> Norm: step that computes hashes has parameters
09:31:53 <jfuller> Norm: Lets investigate the notion of removing parameters alltogether and dig into allowing options with map type
09:32:38 <jfuller> Norm: as an author, how do with options allow options defined in the pipeline automatically bind
09:33:41 <jfuller> Henry: we dont have to mandate it, make it flexible and default it
09:34:01 <jfuller> Henry: the default option for option parameters are parameters -- {scribe - ummmmm }
09:36:51 <jfuller> Norm: exp shows that its not even in the 90% ?
09:37:15 <jfuller> Henry: making it a flag on option, allows u to do that, then having to say paramater option are ...
09:38:53 <jfuller> Henry: at the commandline thats where magic should happen
09:39:22 <jfuller> Norm: this has the advantage of getting rid of params
09:40:08 <jfuller> Norm: we need inherit=true .... the case is that the value is true today
09:40:50 <jfuller> Norm: explaining how binding works/flows through to p:xslt
09:42:11 <jfuller> Henry: here is a v1 pipeline example with params, and here is v2 equiv
09:44:28 <jfuller> Henry: if foo = type map there might be new syntax with option
09:49:33 <jfuller> http://www.w3.org/TR/xslt-30/#map
10:08:04 <jfuller> jfuller has joined #xproc
10:09:29 <Norm> Norm has joined #xproc
10:12:36 <jfuller> Norm: we dont need parameters
10:12:45 <jfuller> Norm: talked ourselves around too ...
10:12:47 <Norm> we don't need p:parameters or p:with-param
10:17:23 <jfuller> Henry: xpath funcs that have signatures, you may get some value
10:18:52 <jfuller> Henry: in v1 variables contain strings
10:19:08 <jfuller> Henry/Norm: we are not going to do that anymore
10:22:35 <Norm> ACTION: Norm to write up our revised parameter story
10:23:07 <jfuller> Norm: the focus for vnext is usability, I think we should consider some syntactic shortcut
10:25:16 <Norm> href= and data= on p:input (equivalent to a single nested p:document or p:data element)
10:25:25 <Norm> Maybe even inventing a syntax for port=
10:26:03 <jfuller> Henry: do you want do (Norm) articulate your concern about variables
10:26:14 <jfuller> Norm: I think its problematic that we require all variables to be at the top of a compound step
10:26:37 <jfuller> Norm: encourage to use maps, if we should allow variables to occur in different places
10:26:50 <jfuller> scribe: Liam has joined us
10:27:37 <liam> liam has joined #xproc
10:28:14 <jfuller> Henry: how do u get an output of  step to a variable ?
10:29:08 <jfuller> Henry: putting a group in provides a scope, only one set of rules required
10:29:40 <jfuller> Henry: we would have to invent ... we could consider implicit p:group ...
10:30:12 <jfuller> Henry: we tried hard to p:group transparent
10:30:32 <jfuller> Henry: its not true that the step inside the group are siblings of the steps outside the group
10:31:14 <jfuller> Norm: we could ... in vnext, if p:variable does not read from a port....
10:31:20 <jfuller> Henry: that does not solve your use case
10:31:52 <jfuller> Henry: one of the consequences of allowing this, there is an implicit sync point ... anyone who references that variable has to wait until the step is compelte
10:31:57 <jfuller> Norm: I now remember ...
10:32:07 <jfuller> (goes to the post board)
10:34:48 <jfuller> Norm: (demonstrates issue with allowing variable decl in middle of pipeline)
10:35:06 <jfuller> Henry: to make that a syntactical valid pipeline,  put a p:group around
10:37:21 <jfuller> Norm: the other topic is how to deal with binary
10:39:39 <jfuller> Alex thread - http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0006.html
10:40:21 <jfuller> Vojtech - http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0020.html
10:41:48 <jfuller> Vojtech xml prague paper -  http://archive.xmlprague.cz/2012/presentations/XProc_Beyond_application_xml.pdf
10:42:52 <ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0005.html
10:43:56 <jfuller> Jim: What do we mean by resource manager ? (1 hr ago)
10:44:37 <jfuller> Henry: our experience ... we had a resource manager which was an implementation detail, when any step involved invoking a URI it would check the resource manager if it had a cached copy
10:44:50 <jfuller> Henry: it was more then that, it was typed
10:45:10 <jfuller> Hentry: notion of resource and processed resource, essentially data model instances
10:45:59 <jfuller> Henry: example, you could get the internal compiled form of the stylesheet .
10:46:14 <jfuller> Henry: we would say 'no doc is ever fetched twice'
10:46:32 <jfuller> Henry: global resource manager was higher scope then an individual pipeline instance, also had expiry checking
10:46:44 <jfuller> Henry: resource managers could be chained ... it could look up the hierarchy
10:47:13 <jfuller> Henry: all of that was an 'efficiency story' but we also used it for several other purposes
10:48:39 <jfuller> Henry: I think that we used the resource manager to deal with document sets ... the step that produced them had to have a naming scheme, so needed prior knowledge, not ideal
10:48:59 <Zakim> Zakim has left #xproc
10:49:06 <jfuller> Henry: that required somewhere to put these things
10:49:58 <jfuller> Norm: my impl has a resource manager that basically does the same thing, any step that produces a document that makes a request to the web to make a document
10:50:16 <ht> s/that makes/or that makes/
10:50:24 <jfuller> Norm: you can satisfy the case where a doc uses xinclude
10:50:48 <jfuller> Liam: instace or sequence o xdm resources
10:50:56 <jfuller> Norm: my impl has xdm instances
10:51:31 <jfuller> Henry: the crucial aspect of what you just said, is that pipeline outputs can get stored in the resource manager ...
10:52:02 <jfuller> Henry: at the extreme end, remember the orbean arch, where there is no notion of ports, no notion of connection ... all connectivity is via uri
10:52:32 <jfuller> Henry: some uris are 'engine internal' ... thats how the topology of the pipeline gets built up
10:53:49 <jfuller> Henry: what Alex proposal amounts too: we will stick that floats through the pipe is xml, resource manager will store the non xml ... definition of a handle
10:54:06 <jfuller> Norm: what do we want to do with a binary in a pipeline ?
10:54:20 <jfuller> Norm: imagine a pipeline with digital signatures ...
10:54:38 <jfuller> Norm: we could invent a p:serialise step ...
10:54:58 <jfuller> Norm: steps that dont care about binary, dont care, steps that care about binaries need to interrogate resource manager
10:55:37 <jfuller> Norm: p:store, p:http-request has to be smart enough
10:58:58 <jfuller> Norm: it is attractive to do this w/o amending the xdm
10:59:04 <jfuller> Jim: +1
10:59:08 <jfuller> Henry: I do too
11:01:40 <jfuller> from Alex Muir http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
11:02:43 <jfuller> he asks if there could be more control over a potential resource manager, concerned about memory usage
11:03:16 <jfuller> he also proposes a simplification of parameters using resource manager (interesting, but we removed them)
11:08:44 <jfuller> Norm: if we decide to address binary using Resource manager, we may need to consider a p:resource-manager step which would allow config of resource manager
11:10:17 <jfuller> Philip Fennell email - http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html
11:10:53 <jfuller> Henry: I am uncomfortable with using private uri scheme
11:11:17 <jfuller> Henry: though its prob ok, they really have no meaning outside the pipeline
11:12:53 <jfuller> Norm: I dont think we have to say anything about the scheme
11:13:46 <jfuller> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html
11:17:53 <jfuller> Norm: I think we should attempt binary solution as provided by Alex
11:19:10 <jfuller> Norm:c:data is the wrapper we use for base64  binary
11:21:51 <jfuller> Norm: if you do an http-request when u get a text doc, u get a c:body element with encoding of base64 and the body contains base64 string directly
11:23:04 <Norm> http://tests.xproc.org/tests/required/http-request-004.xml
11:27:43 <Norm> Henry: We can ameliorate teh backwards incopatibility with a p:base64-encode shim step
11:27:49 <Norm> s/teh/the/
11:28:38 <jfuller> Henry: we are going to need some examples, signature example
11:28:43 <Norm> Norm has left #xproc
11:28:46 <Norm> Norm has joined #xproc
11:28:48 <jfuller> Henry: enc/dec steps ...
11:29:22 <Norm> We can also have a p:serialize step that puts a serialized representation in the cache
11:29:54 <jfuller> Henry: but not having a story about uris in resource manager, if we had a uri scheme for the resource manager entries then we would not need p:serialise to the cache because p:store would do the job
11:31:15 <jfuller> Norm: what p:store is impl defined
11:32:21 <jfuller> Norm: maybe we overload p:store ... with no href attribute pushes to resource manager
11:35:55 <jfuller> Henry: that is fine, what I didnt want is to have significant decrease in all their pipelines
11:36:32 <jfuller> Norm: define a handle as c:result | c:data which has content-type and href attribute
11:36:48 <jfuller> Norm: we can also preserve what we do with c:body
11:37:03 <jfuller> Norm: there are only a few contexts where a binary handle is expected today
11:38:58 <jfuller> Jim: any xpath funcs we need to add ?
11:38:59 <jfuller> Norm: only one I can think of is p:content-type
11:39:21 <jfuller> Henry: how could u have a handle uri w/o having a handle element ?
11:39:40 <jfuller> Norm: having a func that gives back binary is not possible
11:40:36 <jfuller> Norm: break for lunch and we come back and review v2 req docs
12:18:08 <Norm> Norm has joined #xproc
12:18:47 <jfuller> jfuller has joined #xproc
12:32:50 <ht> ht has joined #xproc
13:08:09 <Norm> Reconvened.
13:08:21 <Norm> Norm: Let's review the shorter requirements document: v
13:08:22 <Norm> http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml
13:21:23 <jfuller> Norm: we have a story for 4.1 and 4.2
13:21:34 <jfuller> Norm: we all to drop 4.3 Compact Syntax
13:21:43 <jfuller> Norm: we all agree on 4.4
13:21:52 <jfuller> Henry: we are counting on map
13:22:02 <jfuller> Norm: we cant be finished until XSLT 3.0 ?
13:22:58 <jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0012.html
13:26:25 <jfuller> All: discussing Vojtech response ....
13:26:42 <jfuller> Norm: I would not want to change defaulting rules, at runtime only one of those steps would be selected
13:27:11 <jfuller> Norm: special rules apply to p:when
13:28:11 <jfuller> Henry: I am fine with Vojtech option 1 and for the editor to try it on
13:28:36 <jfuller> Henry: notice that the good thing about talking about it this way, every child of choose has the same arity of output port is now a theorem
13:29:22 <jfuller> Henry: means for coherence, all of those alternatives have the same arity
13:30:37 <jfuller> Norm: choose is magic .. .static rule, all the when must have same arity of ports
13:31:05 <jfuller> Henry: if someone is statically checking a pipeline ... computing the dep graph,
13:31:16 <jfuller> Henry: I need be able to operate the default primary input rules
13:31:44 <jfuller> Norm: default readable ports ... number of funky things .. number of special rules for p:choose et al
13:32:56 <jfuller> Henry: wrapper turned out easy to write
13:33:22 <jfuller> Norm: in the case of try/catch, plumb ports to group, if runs successfully ...
13:34:16 <jfuller> Henry: we need to put notes in the definitions of scoping and defaulting, related to when special rules apply to some compound steps
13:38:52 <jfuller> Jim: can we move on to reviewing 4.7 - step categories
13:39:04 <jfuller> Henry: reviewing previous minutes on the subject, what we do is akin to step registries
13:39:18 <jfuller> Henry: we wasted a lot of time, in v1, talking about user defined compound steps
13:39:42 <jfuller> Henry: vnext should be shorter as v1 spec
13:39:50 <jfuller> Henry: all we do is establish a registry
13:39:58 <jfuller> Henry: which registers a bunch of steps
13:40:13 <jfuller> scribe: Liam has come back
13:41:17 <Norm> Norm has left #xproc
13:41:18 <jfuller> Norm: we've gone meta meta until your head explodes !
13:41:50 <jfuller> Henry: the ITF works like this, establishing a registry and giving it an initial population
13:42:22 <jfuller> Henry: you can add stuff, w/o having to change something normative
13:42:54 <jfuller> Norm: xpointer does things this way
13:43:03 <jfuller> Henry: the amount of scrutiny required would be minimal
13:43:30 <jfuller> Henry: you raised indirectly, does it take a WG to register a step ?
13:44:01 <jfuller> Norm: if we are going to allow registries ... we allow everyone to allow their own steps in their own namespaces
13:44:25 <jfuller> Henry: do u think about publishing an API
13:44:41 <jfuller> Henry: how do u get your step interoperably ?
13:44:54 <jfuller> Norm: I would rather avoid that
13:45:00 <jfuller> Norm: the registry contains declaration of the step
13:46:22 <jfuller> Henry: to be a conformant processor that says, what the status of each step ?
13:47:47 <jfuller> Henry: if we had done this, the v1.0 step is allowed in v2 ... all of them that has parameters will have to change
13:48:22 <jfuller> Henry: every entry in a step registry, has to be version
13:48:29 <jfuller> Norm: lets assume no registry for v1.0 steps
13:48:43 <jfuller> Norm: agrees that entry in the registry should be versioned ...
13:48:51 <jfuller> Henry: there is some versioning metadata
13:49:13 <jfuller> Jim: what are we getting
13:49:38 <jfuller> Norm: if we go this route, do we want to allow dynamic lookup
13:50:27 <jfuller> Norm: the problem with saying 'you dont need decl' is that a processor that doesnt have decl cant do static checking
13:51:40 <jfuller> Henry: the real question is, w3c process going forward ... this will improve
13:52:03 <jfuller> Norm: who will this, in practice if we had v2 spec + notes
13:52:59 <jfuller> Henry: notes are not normative,
13:53:13 <jfuller> Henry: public registry would be open
13:53:36 <jfuller> Henry: registering something in the W3C namespace would require a recc ... which would be easy to go through recc process
13:54:26 <jfuller> Henry: min could be for a single step,
13:55:24 <jfuller> Liam: I am going to disagree with Henry, if is a requirement of XProc then require a change there ...
13:58:48 <jfuller> Henry: the mechanism can be used in a lightweight way
13:58:58 <jfuller> Liam: you can go to PR and RECC
13:59:05 <jfuller> Henry: 2 drafts and a spec
13:59:24 <liam> liam has joined #xproc
14:00:56 <jfuller> Norm: delete 4.7
14:03:26 <jfuller> Norm: if Alex comes back with set of categories and its a straightforward then all good
14:03:28 <Norm> allow href= and data= on p:input
14:03:33 <Norm> allow port= and step= on p:input
14:03:46 <Norm> make p:inline optional
14:04:14 <Norm> if port=x is specified and step= is not, then the implicit step is the step from which the default readable port would be read
14:13:51 <Norm> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0002.html
14:19:59 <jfuller> scribe: reviewing logging + debugging
14:20:11 <Norm> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
14:24:29 <jfuller> Henry: there has been some work here, to allow ppl to provide hints to the processor
14:26:27 <jfuller> Norm: first section of this, we need to clarify our understanding
14:27:18 <jfuller> Norm: in current spec, we say its an error with parameter input ports
14:29:26 <jfuller> Norm: in the new regime, <p:option name="parameters" params="true"/>
14:33:41 <jfuller> Liam: this maybe related to XSLT tunnel parameters
14:34:54 <jfuller> Norm: pipeline the contains a declare-step, there is no way to know, there is a dam here where parameters dont go through
14:35:22 <jfuller> Henry: if person authors <x:y name="parameters"/> then we get a static error, which is ok
14:36:45 <jfuller> Henry: what would the downside be, if current our tentative parameter design from the morning
14:36:54 <jfuller> Henry: if the user puts nothing at all ...
14:37:22 <jfuller> Liam: its close to something I want, e.g. if I make a typo in a param name then I get no error,
14:37:33 <jfuller> Norm: but the xslt step will throw an error (I think)
14:38:51 <jfuller> Henry: I always have to go to xmlspec.xsl to find out the param for diff markup
14:42:13 <jfuller> Norm: if a declare-step has no options, then it has an anonymous p:option, that pass silently through
14:46:29 <jfuller> Norm: first, a declare-step that does not declare any parameters gets an implicit an anonymous parameters
14:46:51 <jfuller> Norm: steps inside a pipeline that have a paramater option that has no parameters, inherit from parent
14:47:42 <jfuller> Henry: we now need 2 examples, one explicit and one implicit
14:47:54 <jfuller> Henry: all for it
14:48:54 <Norm> Norm has joined #xproc
14:49:00 <Norm> rrsagent, draft minutes
14:49:00 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-xproc-minutes.html Norm
14:49:16 <Norm> rrsagent, set lots world-visible
14:49:16 <RRSAgent> I'm logging. I don't understand 'set lots world-visible', Norm.  Try /msg RRSAgent help
14:49:24 <Norm> rrsagent, set logs world-visible
14:50:31 <Norm> rrsagent, hlep
14:50:31 <RRSAgent> I'm logging. I don't understand 'hlep', Norm.  Try /msg RRSAgent help
14:50:33 <Norm> rrsagent, hhelp
14:50:33 <RRSAgent> I'm logging. I don't understand 'hhelp', Norm.  Try /msg RRSAgent help
14:50:35 <Norm> rrsagent, hhelp
14:50:35 <RRSAgent> I'm logging. I don't understand 'hhelp', Norm.  Try /msg RRSAgent help
14:50:37 <Norm> rrsagent, help
14:55:31 <jfuller> jfuller has joined #xproc
15:02:28 <jfuller> jfuller has joined #xproc
15:02:37 <Norm> Norm has joined #xproc
15:27:40 <liam> liam has joined #xproc
15:39:05 <jfuller> scribe - Norm providing examples of v1.0 versus vnext
16:15:31 <jfuller> scribe- after much discussion
16:15:50 <jfuller> Liam: (proposed some syntax) with p:step() as xpath extension function
16:16:05 <jfuller> Norm: I would not be able to do static analysis
16:17:33 <jfuller> Norm: one other bit of syntax, add step attribute to p:with-option, p:with-param
16:24:51 <jfuller> Norm: we have to decide context for AVT, perhaps there are 2 approaches, empty or default readable port
16:29:56 <jfuller> Henry: (explains avt as true shortcut)
17:26:40 <ht> ht has joined #xproc
17:30:44 <Norm> Norm has joined #xproc
17:49:26 <jfuller> jfuller has joined #xproc