- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 27 Nov 2012 16:59:09 -0600
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2ehjey7nm.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2012/11/01-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 223, 01/02 Nov 2012
[2]Agenda
See also: [3]IRC log
Attendees
Present
Henry, Norm, Jim, Liam (partial)
Regrets
Vojtech, Mohamed, Alex
Chair
Norm
Scribe
Jim (mostly) and Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon 15 Nov
4. [8]Parameters
5. [9]Test suite
6. [10]Review of the comments list
* [11]Summary of Action Items
--------------------------------------------------------------------------
01 Nov 2012
Accept this agenda?
-> [12]http://www.w3.org/XML/XProc/2012/11/01-agenda
<jfuller> comments
<jfuller>
[13]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
<jfuller>
[14]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?
-> [15]http://www.w3.org/XML/XProc/2012/10/18-minutes
Accepted.
Next meeting: telcon 15 Nov
Accepted.
Parameters
->
[16]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
Norm: step that computes hashes has parameters
... Lets investigate the notion of removing parameters alltogether and dig
into allowing options with map type
... as an author, how do with options allow options defined in the
pipeline automatically bind
Henry: we dont have to mandate it, make it flexible and default it
... the default option for option parameters are parameters -- {scribe -
ummmmm }
Norm: exp shows that its not even in the 90% ?
Henry: making it a flag on option, allows u to do that, then having to say
paramater option are ...
... at the commandline thats where magic should happen
Norm: this has the advantage of getting rid of params
... we need inherit=true .... the case is that the value is true today
... explaining how binding works/flows through to p:xslt
Henry: here is a v1 pipeline example with params, and here is v2 equiv
... if foo = type map there might be new syntax with option
[17]http://www.w3.org/TR/xslt-30/#map
Norm: we dont need parameters
... talked ourselves around too ...
<Norm> we don't need p:parameters or p:with-param
Henry: xpath funcs that have signatures, you may get some value
... in v1 variables contain strings
Henry/Norm: we are not going to do that anymore
<Norm> ACTION: Norm to write up our revised parameter story [recorded in
[18]http://www.w3.org/2012/11/01-xproc-minutes.html#action01]
Norm: the focus for vnext is usability, I think we should consider some
syntactic shortcut
<Norm> href= and data= on p:input (equivalent to a single nested
p:document or p:data element)
<Norm> Maybe even inventing a syntax for port=
Henry: do you want do (Norm) articulate your concern about variables
Norm: I think its problematic that we require all variables to be at the
top of a compound step
... encourage to use maps, if we should allow variables to occur in
different places
<scribe> scribe: Liam has joined us
Henry: how do u get an output of step to a variable ?
... putting a group in provides a scope, only one set of rules required
... we would have to invent ... we could consider implicit p:group ...
... we tried hard to p:group transparent
... its not true that the step inside the group are siblings of the steps
outside the group
Norm: we could ... in vnext, if p:variable does not read from a port....
Henry: that does not solve your use case
... 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
Norm: I now remember ...
(goes to the post board)
[19]Image of pipeline with variables
Norm: (demonstrates issue with allowing variable decl in middle of
pipeline)
Henry: to make that a syntactical valid pipeline, put a p:group around
Norm: the other topic is how to deal with binary
Alex thread -
[20]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0006.html
Vojtech -
[21]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0020.html
Vojtech xml prague paper -
[22]http://archive.xmlprague.cz/2012/presentations/XProc_Beyond_application_xml.pdf
<ht>
[23]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0005.html
Jim: What do we mean by resource manager ? (1 hr ago)
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
... it was more then that, it was typed
Hentry: notion of resource and processed resource, essentially data model
instances
Henry: example, you could get the internal compiled form of the stylesheet
.
... we would say 'no doc is ever fetched twice'
... global resource manager was higher scope then an individual pipeline
instance, also had expiry checking
... resource managers could be chained ... it could look up the hierarchy
... all of that was an 'efficiency story' but we also used it for several
other purposes
... 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
... that required somewhere to put these things
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
... you can satisfy the case where a doc uses xinclude
Liam: instace or sequence o xdm resources
Norm: my impl has xdm instances
Henry: the crucial aspect of what you just said, is that pipeline outputs
can get stored in the resource manager ...
... at the extreme end, remember the orbean arch, where there is no notion
of ports, no notion of connection ... all connectivity is via uri
... some uris are 'engine internal' ... thats how the topology of the
pipeline gets built up
... 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
Norm: what do we want to do with a binary in a pipeline ?
... imagine a pipeline with digital signatures ...
... we could invent a p:serialise step ...
... steps that dont care about binary, dont care, steps that care about
binaries need to interrogate resource manager
... p:store, p:http-request has to be smart enough
... it is attractive to do this w/o amending the xdm
Jim: +1
Henry: I do too
from Alex Muir
[24]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
he asks if there could be more control over a potential resource manager,
concerned about memory usage
he also proposes a simplification of parameters using resource manager
(interesting, but we removed them)
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
Philip Fennell email -
[25]http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html
Henry: I am uncomfortable with using private uri scheme
... though its prob ok, they really have no meaning outside the pipeline
Norm: I dont think we have to say anything about the scheme
[26]http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html
Norm: I think we should attempt binary solution as provided by Alex
... c:data is the wrapper we use for base64 binary
... 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
<Norm> [27]http://tests.xproc.org/tests/required/http-request-004.xml
<Norm> Henry: We can ameliorate the backwards incopatibility with a
p:base64-encode shim step
Henry: we are going to need some examples, signature example
... enc/dec steps ...
<Norm> We can also have a p:serialize step that puts a serialized
representation in the cache
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
Norm: what p:store is impl defined
... maybe we overload p:store ... with no href attribute pushes to
resource manager
Henry: that is fine, what I didnt want is to have significant decrease in
all their pipelines
Norm: define a handle as c:result | c:data which has content-type and href
attribute
... we can also preserve what we do with c:body
... there are only a few contexts where a binary handle is expected today
Jim: any xpath funcs we need to add ?
Norm: only one I can think of is p:content-type
Henry: how could u have a handle uri w/o having a handle element ?
Norm: having a func that gives back binary is not possible
... break for lunch and we come back and review v2 req docs
<Norm> Reconvened.
<Norm> Norm: Let's review the shorter requirements document: v
<Norm> [28]http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml
Norm: we have a story for 4.1 and 4.2
... we all to drop 4.3 Compact Syntax
... we all agree on 4.4
Henry: we are counting on map
Norm: we cant be finished until XSLT 3.0 ?
[29]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0012.html
All: discussing Vojtech response ....
Norm: I would not want to change defaulting rules, at runtime only one of
those steps would be selected
... special rules apply to p:when
Henry: I am fine with Vojtech option 1 and for the editor to try it on
... 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
... means for coherence, all of those alternatives have the same arity
Norm: choose is magic .. .static rule, all the when must have same arity
of ports
Henry: if someone is statically checking a pipeline ... computing the dep
graph,
... I need be able to operate the default primary input rules
Norm: default readable ports ... number of funky things .. number of
special rules for p:choose et al
Henry: wrapper turned out easy to write
Norm: in the case of try/catch, plumb ports to group, if runs successfully
...
Henry: we need to put notes in the definitions of scoping and defaulting,
related to when special rules apply to some compound steps
Jim: can we move on to reviewing 4.7 - step categories
Henry: reviewing previous minutes on the subject, what we do is akin to
step registries
... we wasted a lot of time, in v1, talking about user defined compound
steps
... vnext should be shorter as v1 spec
... all we do is establish a registry
... which registers a bunch of steps
<scribe> scribe: Liam has come back
Norm: we've gone meta meta until your head explodes !
Henry: the ITF works like this, establishing a registry and giving it an
initial population
... you can add stuff, w/o having to change something normative
Norm: xpointer does things this way
Henry: the amount of scrutiny required would be minimal
... you raised indirectly, does it take a WG to register a step ?
Norm: if we are going to allow registries ... we allow everyone to allow
their own steps in their own namespaces
Henry: do u think about publishing an API
... how do u get your step interoperably ?
Norm: I would rather avoid that
... the registry contains declaration of the step
Henry: to be a conformant processor that says, what the status of each
step ?
... if we had done this, the v1.0 step is allowed in v2 ... all of them
that has parameters will have to change
... every entry in a step registry, has to be version
Norm: lets assume no registry for v1.0 steps
... agrees that entry in the registry should be versioned ...
Henry: there is some versioning metadata
Jim: what are we getting
Norm: if we go this route, do we want to allow dynamic lookup
... the problem with saying 'you dont need decl' is that a processor that
doesnt have decl cant do static checking
Henry: the real question is, w3c process going forward ... this will
improve
Norm: who will this, in practice if we had v2 spec + notes
Henry: notes are not normative,
... public registry would be open
... registering something in the W3C namespace would require a recc ...
which would be easy to go through recc process
... min could be for a single step,
Liam: I am going to disagree with Henry, if is a requirement of XProc then
require a change there ...
Henry: the mechanism can be used in a lightweight way
Liam: you can go to PR and RECC
Henry: 2 drafts and a spec
Norm: delete 4.7
... if Alex comes back with set of categories and its a straightforward
then all good
<Norm> allow href= and data= on p:input
<Norm> allow port= and step= on p:input
<Norm> make p:inline optional
<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
<Norm>
[30]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0002.html
<scribe> scribe: reviewing logging + debugging
<Norm>
[31]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
Henry: there has been some work here, to allow ppl to provide hints to the
processor
Norm: first section of this, we need to clarify our understanding
... in current spec, we say its an error with parameter input ports
... in the new regime, <p:option name="parameters" params="true"/>
Liam: this maybe related to XSLT tunnel parameters
Norm: pipeline the contains a declare-step, there is no way to know, there
is a dam here where parameters dont go through
Henry: if person authors <x:y name="parameters"/> then we get a static
error, which is ok
... what would the downside be, if current our tentative parameter design
from the morning
... if the user puts nothing at all ...
Liam: its close to something I want, e.g. if I make a typo in a param name
then I get no error,
Norm: but the xslt step will throw an error (I think)
Henry: I always have to go to xmlspec.xsl to find out the param for diff
markup
Norm: if a declare-step has no options, then it has an anonymous p:option,
that pass silently through
... first, a declare-step that does not declare any parameters gets an
implicit an anonymous parameters
... steps inside a pipeline that have a paramater option that has no
parameters, inherit from parent
Henry: we now need 2 examples, one explicit and one implicit
... all for it
scribe - Norm providing examples of v1.0 versus vnext
<examples xmlns:p="…" xmlns:c="…">
<p:pipeline>
<p:xslt>
<p:input port="stylesheet">
<p:document href="docbook.xsl"/>
</p:input>
</p:xslt>
</p:pipeline>
<p:pipeline>
<p:xslt>
<p:input port="stylesheet" href="docbook.xsl"/>
</p:xslt>
</p:pipeline>
<p:pipeline>
<p:xslt>
<p:input port="stylesheet">
<p:document href="docbook.xsl"/>
</p:input>
<p:with-param name="page-size" select="'A4'"/>
<p:input port="parameters"/>
</p:xslt>
</p:pipeline>
<p:pipeline>
<p:xslt>
<p:input port="stylesheet" href="docbook.xsl"/>
<p:with-param name="page-size" select="/config/page-size" as="xs:string"
step="configuration"/>
<!--
<p:with-param name="page-size" select="/config/page-size" as="xs:string">
<p:pipe step="configuration" port="result"/>
</p:with-param>
<p:with-param name="page-size" select="p:pipe('configuration','result')/config/page-size"
as="xs:string"/>
- has to be static names
- with-param still has a default binding
<p:with-param name="page-size" select="'A4'"/>
-->
<!--
<p:with-param name="page-size" select="(map:get($parameters, 'page-size'), 'A4')[1]"/>
<p:with-param name="page-size" select="if map:contains($parameters, 'page-size')
then map:get($parameters, 'page-size')
else 'A4'"/>
<p:with-option name="parameters" select="map{'page-size' := 'A4'}"/>
<p:with-option name="parameters" select="map:new(($parameters, map{'page-size' := 'A4'}))"/>
-->
</p:xslt>
</p:pipeline>
<p:declare-step name="main">
<p:input port="source"/>
<p:output port="source"/>
<p:input port="myparams" kind="parameters"/>
<p:xslt>
<p:input port="stylesheet">
<p:document href="docbook.xsl"/>
</p:input>
<p:input port="parameters">
<p:pipe step="main" port="myparams"/>
</p:input>
</p:xslt>
</p:declare-step>
<p:declare-step name="main">
<p:input port="source"/>
<p:output port="source"/>
<p:option name="myparams" parameters="true"/>
<p:xslt>
<p:input port="stylesheet" href="docbook.xsl"/>
<p:with-option name="parameters" select="$myparams"/>
</p:xslt>
</p:declare-step>
<p:declare-step name="main">
<p:input port="source"/>
<p:output port="source"/>
<p:input port="parameters" kind="parameters" primary="true"/>
<p:input port="optionalp" kind="parameters"/>
<p:xslt>
<p:input port="stylesheet">
<p:document href="docbook.xsl"/>
</p:input>
</p:xslt>
<p:xslt>
<p:input port="stylesheet">
<p:document href="docbook.xsl"/>
</p:input>
<p:input port="parameters">
<p:pipe step="main" port="optionalp"/>
</p:input>
</p:xslt>
</p:declare-step>
<p:declare-step name="main">
<p:input port="source"/>
<p:output port="source"/>
<p:option name="parameters" parameters="true"/>
<p:option name="optionalp" parameters="true"/>
<p:xslt>
<p:input port="stylesheet" href="docbook.xsl"/>
<!-- it is a static error to leave out the with-option below
OR you get no parameters at all
-->
<p:with-option name="parameters" select="$parameters"/>
<!--
<p:with-option name="parameters" select="()"/>
-->
</p:xslt>
<p:xslt>
<p:input port="stylesheet" href="docbook.xsl"/>
<p:with-option name="parameters" select="$optionalp"/>
</p:xslt>
</p:declare-step>
<p:declare-step>
<p:output port="result"/>
<p:parameters name="params">
<p:with-param port="parameters" name="input1" select="'value1'">
<p:empty/>
</p:with-param>
<p:input port="parameters">
<p:inline>
<c:param-set>
<c:param name="input1" value="value2"/>
<c:param name="input2" value="value1"/>
</c:param-set>
</p:inline>
</p:input>
<p:with-param port="parameters" name="param1" select="'value1'">
<p:empty/>
</p:with-param>
<p:with-param port="parameters" name="input2" select="'value2'">
<p:empty/>
</p:with-param>
</p:parameters>
<p:identity name="pick1">
<p:input port="source" select="/c:param-set/c:param[@name='input1']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:identity name="pick2">
<p:input port="source" select="/c:param-set/c:param[@name='input2']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:identity name="pick3">
<p:input port="source" select="/c:param-set/c:param[@name='param1']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:wrap-sequence wrapper="c:param-set">
<p:input port="source">
<p:pipe step="pick1" port="result"/>
<p:pipe step="pick2" port="result"/>
<p:pipe step="pick3" port="result"/>
</p:input>
</p:wrap-sequence>
</p:declare-step>
<p:declare-step>
<p:output port="result"/>
<p:parameters name="params1">
<p:with-option name="parameters" select="map{'input1' := 'value1'}"/>
</p:parameters>
<p:parameters name="params2">
<p:input port="parameters">
<p:inline>
<c:param-set>
<c:param name="input1" value="value2"/>
<c:param name="input2" value="value1"/>
</c:param-set>
</p:inline>
</p:input>
</p:parameters>
<p:parameters name="params3">
<p:with-param name="param1" select='value2'"/>
<p:with-param name="input2" select="'value2'"/>
</p:parameters>
<p:parameters name="params">
<p:input port="parameters">
<p:pipe step="params1" port="result"/>
<p:pipe step="params2" port="result"/>
<p:pipe step="params3" port="result"/>
</p:input>
</p:parameters>
<p:identity name="pick1">
<p:input port="source" select="/c:param-set/c:param[@name='input1']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:identity name="pick2">
<p:input port="source" select="/c:param-set/c:param[@name='input2']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:identity name="pick3">
<p:input port="source" select="/c:param-set/c:param[@name='param1']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:wrap-sequence wrapper="c:param-set">
<p:input port="source">
<p:pipe step="pick1" port="result"/>
<p:pipe step="pick2" port="result"/>
<p:pipe step="pick3" port="result"/>
</p:input>
</p:wrap-sequence>
</p:declare-step>
<p:declare-step version="1.0" name="main">
<p:input port="source"/>
<p:output port="result"/>
<p:parameters name="params">
<p:input port="parameters">
<p:inline>
<c:param-set>
<c:param name="param1" value="value1"/>
<c:param name="param2" namespace="http://www.example.com"
value="value2"/>
<c:param name="param1" value="valueX"/>
</c:param-set>
</p:inline>
</p:input>
</p:parameters>
<p:identity name="pick1">
<p:input port="source" select="/c:param-set/c:param[@name='param1']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:identity name="pick2">
<p:input port="source" select="/c:param-set/c:param[@name='param2']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:wrap-sequence wrapper="c:param-set">
<p:input port="source">
<p:pipe step="pick1" port="result"/>
<p:pipe step="pick2" port="result"/>
</p:input>
</p:wrap-sequence>
</p:declare-step>
<p:declare-step version="1.0" name="main">
<p:input port="source"/>
<p:output port="result"/>
<p:parameters name="params">
<p:input port="parameters">
<c:param-set>
<c:param name="param1" value="value1"/>
<c:param name="param2" namespace="http://www.example.com"
value="value2"/>
<c:param name="param1" value="valueX"/>
</c:param-set>
</p:input>
</p:parameters>
<p:identity name="pick1">
<p:input port="source" select="/c:param-set/c:param[@name='param1']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:identity name="pick2">
<p:input port="source" select="/c:param-set/c:param[@name='param2']">
<p:pipe step="params" port="result"/>
</p:input>
</p:identity>
<p:wrap-sequence wrapper="c:param-set">
<p:input port="source">
<p:pipe step="pick1" port="result"/>
<p:pipe step="pick2" port="result"/>
</p:input>
</p:wrap-sequence>
</p:declare-step>
</examples>
scribe- after much discussion
Liam: (proposed some syntax) with p:step() as xpath extension function
Norm: I would not be able to do static analysis
... one other bit of syntax, add step attribute to p:with-option,
p:with-param
... we have to decide context for AVT, perhaps there are 2 approaches,
empty or default readable port
Henry: (explains avt as true shortcut)
02 Nov 2012
Test suite
Jim: Wrt to categorizing the 1.0 solutions, do we want to look at
deficiencies in the test suite?
... And do we need new tests for V.next
Norm: We'll certainly need new tests
... Converting all the current tests to V.next
Henry: We added a version and an edition attribute to the metadata and
made that be a space-separated list of identifiers
... So you can have a test that works under multiple versions and the
harness takes a version number.
Some discussion of the nature of the XML Schema tests.
Jim: Are we going to propose a different mount point in the repo?
Norm: I think I'm going to suggest doing the version number thing so that
we have one test to correct if there are ambiguities
-> [32]http://tests.xproc.org/testsuite/coverage.html
Jim: For steps in general, we seem to have good coverage, but perhaps not
in errors and negative tests.
... What about error codes for V.next?
Norm: I think we just invent new ones if we don't have good values
Jim: How do we get the tests?
Norm: Implementors wrote most of the tests.
Henry: Is there a schema? Can we ask users to write tests that conform to
the schema?
Norm: Yes, and there are docs, though I should review them; there was some
drift.
... We can turn use cases from the requirements document into tests pretty
easily, I hope
Review of the comments list
->
[33]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/thread.html
->
[34]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/0003.html
Henry: We're going to have to revisit this in the context of our ideas
about compound-step and containers; we should consider these comments in
the course of that work.
Norm: Makes sense to me.
->
[35]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/0004.html
Editorial
Jim proposed errata:
->
[36]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0000.html
Henry: It's easy to be confused by this.
-> [37]http://tests.xproc.org/tests/required/err-s0018-002.xml
Norm: Tim's right.
->[38]http://www.w3.org/TR/xslt20/#dt-pattern
Norm: Possibly an erratum since it should be an error
... You'd have to do static analysis of every XPath expression to compute
the dependency graph and in the case of collection($foo), it wouldn't be
possible.
<scribe> ACTION: Norm to put document metadata on a future agenda
-> [39]http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0011.html
Summary of Action Items
[NEW] ACTION: Norm to write up our revised parameter story
[NEW] ACTION: Norm to put document metadata on a future agenda
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [40]scribe.perl version 1.137 ([41]CVS
log)
$Date: 2012-11-27 22:57:33 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2012/11/01-agenda
3. http://www.w3.org/2012/11/01-xproc-irc
4. http://www.w3.org/XML/XProc/2012/11/01-minutes#agenda
5. http://www.w3.org/XML/XProc/2012/11/01-minutes#item01
6. http://www.w3.org/XML/XProc/2012/11/01-minutes#item02
7. http://www.w3.org/XML/XProc/2012/11/01-minutes#item03
8. http://www.w3.org/XML/XProc/2012/11/01-minutes#item04
9. http://www.w3.org/XML/XProc/2012/11/01-minutes#item05
10. http://www.w3.org/XML/XProc/2012/11/01-minutes#item06
11. http://www.w3.org/XML/XProc/2012/11/01-minutes#ActionSummary
12. http://www.w3.org/XML/XProc/2012/11/01-agenda
13. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
14. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0006.html
15. http://www.w3.org/XML/XProc/2012/10/18-minutes
16. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0014.html
17. http://www.w3.org/TR/xslt-30/#map
18. http://www.w3.org/2012/11/01-xproc-minutes.html#action01
20. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0006.html
21. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0020.html
22. http://archive.xmlprague.cz/2012/presentations/XProc_Beyond_application_xml.pdf
23. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0005.html
24. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
25. http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html
26. http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0012.html
27. http://tests.xproc.org/tests/required/http-request-004.xml
28. http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml
29. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0012.html
30. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0002.html
31. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0004.html
32. http://tests.xproc.org/testsuite/coverage.html
33. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/thread.html
34. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/0003.html
35. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/0004.html
36. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Oct/0000.html
37. http://tests.xproc.org/tests/required/err-s0018-002.xml
38. http://www.w3.org/TR/xslt20/#dt-pattern
39. http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0011.html
40. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
41. http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 27 November 2012 22:59:41 UTC