W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2012

XProc Minutes 01/02 Nov 2012 (face-to-face)

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 November 2012 22:59:41 GMT