XML Processing Model WG

01 Nov 2012


See also: IRC log


Henry, Norm, Jim
Norm, Liam has joined us, Liam has come back, reviewing logging + debugging


Date: 1 Nov 2012

<scribe> Meeting: 223

<scribe> Scribe: Norm

<scribe> ScribeNick: norm

Accept this agenda?

-> http://www.w3.org/XML/XProc/2012/11/01-agenda

<jfuller> comments

<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html

<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0006.html

Henry: We should try to talk about some design issues: binary data/resource manager; parameters

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2012/10/18-minutes


Next meeting: telcon 15 Nov



-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0014.html

Random points of discussion:

Where do maps fit in the data model?

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

Henry: We could allow multiple with-params with the same name and that would allow you to have each parameter have its own line.

<ht> <p:with-param name="parameters" pname="foo" select="[xpath expression]"/>

<ht> would be an alternative to

Norm wonders if we really need to support the case where a pipeline can have *more than one* set of parameters.

scribe: Ostensibly its for the case where a pipeline has two XSLT steps and need two different sets of parameters.

<ht> <p:with-param name="parameters" select="merge-maps(map(('foo',[xpath expression])))"/>

We could do this:

<p:with-param group="parameters" name="foo" select="[expr]"/>

<p:with-param name="foo" select='[expr]'/>

Henry: That makes the 'name' of a p:with-param very different from the name on a p:with-option

We all agree that V.next will be XDM/XPath 2.0 based

<jfuller> Norm: step that computes hashes has parameters

<jfuller> Norm: Lets investigate the notion of removing parameters alltogether and dig into allowing options with map type

<jfuller> Norm: as an author, how do with options allow options defined in the pipeline automatically bind

<jfuller> Henry: we dont have to mandate it, make it flexible and default it

<jfuller> Henry: the default option for option parameters are parameters -- {scribe - ummmmm }

<jfuller> Norm: exp shows that its not even in the 90% ?

<jfuller> Henry: making it a flag on option, allows u to do that, then having to say paramater option are ...

<jfuller> Henry: at the commandline thats where magic should happen

<jfuller> Norm: this has the advantage of getting rid of params

<jfuller> Norm: we need inherit=true .... the case is that the value is true today

<jfuller> Norm: explaining how binding works/flows through to p:xslt

<jfuller> Henry: here is a v1 pipeline example with params, and here is v2 equiv

<jfuller> Henry: if foo = type map there might be new syntax with option

<jfuller> http://www.w3.org/TR/xslt-30/#map

<jfuller> Norm: we dont need parameters

<jfuller> Norm: talked ourselves around too ...

we don't need p:parameters or p:with-param

<jfuller> Henry: xpath funcs that have signatures, you may get some value

<jfuller> Henry: in v1 variables contain strings

<jfuller> Henry/Norm: we are not going to do that anymore

<scribe> ACTION: Norm to write up our revised parameter story [recorded in http://www.w3.org/2012/11/01-xproc-minutes.html#action01]

<jfuller> Norm: the focus for vnext is usability, I think we should consider some syntactic shortcut

href= and data= on p:input (equivalent to a single nested p:document or p:data element)

Maybe even inventing a syntax for port=

<jfuller> Henry: do you want do (Norm) articulate your concern about variables

<jfuller> Norm: I think its problematic that we require all variables to be at the top of a compound step

<jfuller> Norm: encourage to use maps, if we should allow variables to occur in different places

<jfuller> scribe: Liam has joined us

<jfuller> Henry: how do u get an output of step to a variable ?

<jfuller> Henry: putting a group in provides a scope, only one set of rules required

<jfuller> Henry: we would have to invent ... we could consider implicit p:group ...

<jfuller> Henry: we tried hard to p:group transparent

<jfuller> Henry: its not true that the step inside the group are siblings of the steps outside the group

<jfuller> Norm: we could ... in vnext, if p:variable does not read from a port....

<jfuller> Henry: that does not solve your use case

<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

<jfuller> Norm: I now remember ...

<jfuller> (goes to the post board)

<jfuller> Norm: (demonstrates issue with allowing variable decl in middle of pipeline)

<jfuller> Henry: to make that a syntactical valid pipeline, put a p:group around

<jfuller> Norm: the other topic is how to deal with binary

<jfuller> Alex thread - http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0006.html

<jfuller> Vojtech - http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0020.html

<jfuller> Vojtech xml prague paper - http://archive.xmlprague.cz/2012/presentations/XProc_Beyond_application_xml.pdf

<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0005.html

<jfuller> Jim: What do we mean by resource manager ? (1 hr ago)

<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

<jfuller> Henry: it was more then that, it was typed

<jfuller> Hentry: notion of resource and processed resource, essentially data model instances

<jfuller> Henry: example, you could get the internal compiled form of the stylesheet .

<jfuller> Henry: we would say 'no doc is ever fetched twice'

<jfuller> Henry: global resource manager was higher scope then an individual pipeline instance, also had expiry checking

<jfuller> Henry: resource managers could be chained ... it could look up the hierarchy

<jfuller> Henry: all of that was an 'efficiency story' but we also used it for several other purposes

<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

<jfuller> Henry: that required somewhere to put these things

<jfuller> Norm: my impl has a resource manager that basically does the same thing, any step that produces a document or that makes a request to the web to make a document

<jfuller> Norm: you can satisfy the case where a doc uses xinclude

<jfuller> Liam: instace or sequence o xdm resources

<jfuller> Norm: my impl has xdm instances

<jfuller> Henry: the crucial aspect of what you just said, is that pipeline outputs can get stored in the resource manager ...

<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

<jfuller> Henry: some uris are 'engine internal' ... thats how the topology of the pipeline gets built up

<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

<jfuller> Norm: what do we want to do with a binary in a pipeline ?

<jfuller> Norm: imagine a pipeline with digital signatures ...

<jfuller> Norm: we could invent a p:serialise step ...

<jfuller> Norm: steps that dont care about binary, dont care, steps that care about binaries need to interrogate resource manager

<jfuller> Norm: p:store, p:http-request has to be smart enough

<jfuller> Norm: it is attractive to do this w/o amending the xdm

<jfuller> Jim: +1

<jfuller> Henry: I do too

<jfuller> from Alex Muir http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html

<jfuller> he asks if there could be more control over a potential resource manager, concerned about memory usage

<jfuller> he also proposes a simplification of parameters using resource manager (interesting, but we removed them)

<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

<jfuller> Philip Fennell email - http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html

<jfuller> Henry: I am uncomfortable with using private uri scheme

<jfuller> Henry: though its prob ok, they really have no meaning outside the pipeline

<jfuller> Norm: I dont think we have to say anything about the scheme

<jfuller> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html

<jfuller> Norm: I think we should attempt binary solution as provided by Alex

<jfuller> Norm:c:data is the wrapper we use for base64 binary

<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


Henry: We can ameliorate the backwards incopatibility with a p:base64-encode shim step

<jfuller> Henry: we are going to need some examples, signature example

<jfuller> Henry: enc/dec steps ...

We can also have a p:serialize step that puts a serialized representation in the cache

<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

<jfuller> Norm: what p:store is impl defined

<jfuller> Norm: maybe we overload p:store ... with no href attribute pushes to resource manager

<jfuller> Henry: that is fine, what I didnt want is to have significant decrease in all their pipelines

<jfuller> Norm: define a handle as c:result | c:data which has content-type and href attribute

<jfuller> Norm: we can also preserve what we do with c:body

<jfuller> Norm: there are only a few contexts where a binary handle is expected today

<jfuller> Jim: any xpath funcs we need to add ?

<jfuller> Norm: only one I can think of is p:content-type

<jfuller> Henry: how could u have a handle uri w/o having a handle element ?

<jfuller> Norm: having a func that gives back binary is not possible

<jfuller> Norm: break for lunch and we come back and review v2 req docs


Norm: Let's review the shorter requirements document: v


<jfuller> Norm: we have a story for 4.1 and 4.2

<jfuller> Norm: we all to drop 4.3 Compact Syntax

<jfuller> Norm: we all agree on 4.4

<jfuller> Henry: we are counting on map

<jfuller> Norm: we cant be finished until XSLT 3.0 ?

<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0012.html

<jfuller> All: discussing Vojtech response ....

<jfuller> Norm: I would not want to change defaulting rules, at runtime only one of those steps would be selected

<jfuller> Norm: special rules apply to p:when

<jfuller> Henry: I am fine with Vojtech option 1 and for the editor to try it on

<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

<jfuller> Henry: means for coherence, all of those alternatives have the same arity

<jfuller> Norm: choose is magic .. .static rule, all the when must have same arity of ports

<jfuller> Henry: if someone is statically checking a pipeline ... computing the dep graph,

<jfuller> Henry: I need be able to operate the default primary input rules

<jfuller> Norm: default readable ports ... number of funky things .. number of special rules for p:choose et al

<jfuller> Henry: wrapper turned out easy to write

<jfuller> Norm: in the case of try/catch, plumb ports to group, if runs successfully ...

<jfuller> Henry: we need to put notes in the definitions of scoping and defaulting, related to when special rules apply to some compound steps

<jfuller> Jim: can we move on to reviewing 4.7 - step categories

<jfuller> Henry: reviewing previous minutes on the subject, what we do is akin to step registries

<jfuller> Henry: we wasted a lot of time, in v1, talking about user defined compound steps

<jfuller> Henry: vnext should be shorter as v1 spec

<jfuller> Henry: all we do is establish a registry

<jfuller> Henry: which registers a bunch of steps

<jfuller> scribe: Liam has come back

<jfuller> Norm: we've gone meta meta until your head explodes !

<jfuller> Henry: the ITF works like this, establishing a registry and giving it an initial population

<jfuller> Henry: you can add stuff, w/o having to change something normative

<jfuller> Norm: xpointer does things this way

<jfuller> Henry: the amount of scrutiny required would be minimal

<jfuller> Henry: you raised indirectly, does it take a WG to register a step ?

<jfuller> Norm: if we are going to allow registries ... we allow everyone to allow their own steps in their own namespaces

<jfuller> Henry: do u think about publishing an API

<jfuller> Henry: how do u get your step interoperably ?

<jfuller> Norm: I would rather avoid that

<jfuller> Norm: the registry contains declaration of the step

<jfuller> Henry: to be a conformant processor that says, what the status of each step ?

<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

<jfuller> Henry: every entry in a step registry, has to be version

<jfuller> Norm: lets assume no registry for v1.0 steps

<jfuller> Norm: agrees that entry in the registry should be versioned ...

<jfuller> Henry: there is some versioning metadata

<jfuller> Jim: what are we getting

<jfuller> Norm: if we go this route, do we want to allow dynamic lookup

<jfuller> Norm: the problem with saying 'you dont need decl' is that a processor that doesnt have decl cant do static checking

<jfuller> Henry: the real question is, w3c process going forward ... this will improve

<jfuller> Norm: who will this, in practice if we had v2 spec + notes

<jfuller> Henry: notes are not normative,

<jfuller> Henry: public registry would be open

<jfuller> Henry: registering something in the W3C namespace would require a recc ... which would be easy to go through recc process

<jfuller> Henry: min could be for a single step,

<jfuller> Liam: I am going to disagree with Henry, if is a requirement of XProc then require a change there ...

<jfuller> Henry: the mechanism can be used in a lightweight way

<jfuller> Liam: you can go to PR and RECC

<jfuller> Henry: 2 drafts and a spec

<jfuller> Norm: delete 4.7

<jfuller> Norm: if Alex comes back with set of categories and its a straightforward then all good

allow href= and data= on p:input

allow port= and step= on p:input

make p:inline optional

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


<jfuller> scribe: reviewing logging + debugging


<jfuller> Henry: there has been some work here, to allow ppl to provide hints to the processor

<jfuller> Norm: first section of this, we need to clarify our understanding

<jfuller> Norm: in current spec, we say its an error with parameter input ports

<jfuller> Norm: in the new regime, <p:option name="parameters" params="true"/>

<jfuller> Liam: this maybe related to XSLT tunnel parameters

<jfuller> Norm: pipeline the contains a declare-step, there is no way to know, there is a dam here where parameters dont go through

<jfuller> Henry: if person authors <x:y name="parameters"/> then we get a static error, which is ok

<jfuller> Henry: what would the downside be, if current our tentative parameter design from the morning

<jfuller> Henry: if the user puts nothing at all ...

<jfuller> Liam: its close to something I want, e.g. if I make a typo in a param name then I get no error,

<jfuller> Norm: but the xslt step will throw an error (I think)

<jfuller> Henry: I always have to go to xmlspec.xsl to find out the param for diff markup

<jfuller> Norm: if a declare-step has no options, then it has an anonymous p:option, that pass silently through

<jfuller> Norm: first, a declare-step that does not declare any parameters gets an implicit an anonymous parameters

<jfuller> Norm: steps inside a pipeline that have a paramater option that has no parameters, inherit from parent

<jfuller> Henry: we now need 2 examples, one explicit and one implicit

<jfuller> Henry: all for it

Summary of Action Items

[NEW] ACTION: Norm to write up our revised parameter story [recorded in http://www.w3.org/2012/11/01-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/11/01 14:49:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/foo/'foo'/
Succeeded: s/that makes/or that makes/
Succeeded: s/teh/the/
Found Scribe: Norm
Inferring ScribeNick: Norm
Found ScribeNick: norm
Found Scribe: Liam has joined us
Found Scribe: Liam has come back
Found Scribe: reviewing logging + debugging
Scribes: Norm, Liam has joined us, Liam has come back, reviewing logging + debugging
Present: Henry Norm Jim
Agenda: http://www.w3.org/XML/XProc/2012/11/01-agenda
Found Date: 01 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/01-xproc-minutes.html
People with action items: norm

WARNING: Possible internal error: join/leave lines remaining: 
        <jfuller> scribe: Liam has joined us

WARNING: Possible internal error: join/leave lines remaining: 
        <jfuller> scribe: Liam has joined us

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]