W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > May 2008

some comments onMay 1st draft

From: James Fuller <james.fuller.2007@gmail.com>
Date: Wed, 7 May 2008 15:13:31 +0200
Message-ID: <a0ad8ffe0805070613i48517920v23989abad0f2435f@mail.gmail.com>
To: public-xml-processing-model-comments@w3.org

some bits n bobs on the May 1st working draft;


I know this is a larger question, but I will ask anyways ;)

What happens when a URL with a fragement identifier is supplied to the
href attribute of a p:document element ?


What happens when an xml:id attribute defined in the body of a
p:inline element is equivalent to an xml:id attribute within the
pipeline itself ?


Propose slightly changing the following text in section 4.1 p:pipeline
where it states

'If a pipeline does not have a type then that pipeline cannot be
invoked as a step.'


''If a pipeline does not have a type then that pipeline cannot be
invoked as a step in another (in-scope???) pipeline'


it states in section 3.7 Processor annotations;

'When a p:pipeinfo appears as a descendant of p:inline, it has no
special semantics; in that context it must be treated literally as
part of the document to be provided on that port.'

Should we consider extending this behavior for any element in the p:
namespace which shows up as a descendent in a p:inline element; or any
XProc specific namespaces for that matter ?


in section 2.5 Environment it states;

'[Definition: The empty environment contains no readable ports, an
undefined default readable port and ....'

I know the reasons behind this statement, but perhaps we could
consider changing it to

'[Definition: The empty environment contains no readable ports, except
an undefined default readable port and ...'


in section 3 Syntax Overview it states;

'Six kinds of things are named in XProc'

could be reworded to

'There are six types of things that may have a name attribute in XProc'

to clarify we are talking about an attribute


if a p:group is a compound step, for example;

<p:group name="test1"/>

then should we enable it to also have a type attribute to be invoked
by a step in another pipeline ? this would harmonize with p:pipeline,
p:declare-step, etc


Wondering if the WG has considered refactoring viewport-source and
iteration-source so we could have a single element, which p:for-each
and p:viewport could use? Seems to be an opportunity for
simplification there ... though I maybe wrong


reminder for Norm on my p:for-each question

the following compound step should output on default output port the
result of xslt and count step

<p:for-each name="chapters">
 <p:iteration-source select="//chapter"/>

 <p:xslt name="make-html">
   <p:input port="stylesheet">
     <p:document href="http://example.com/xsl/html.xsl"/>

 <p:count name='countstep'/>


what does this compound step do

<p:for-each name="chapters">
 <p:iteration-source select="//chapter"/>
 <p:output port="html-results">
   <p:pipe step="make-html" port="result"/>

 <p:xslt name="make-html">
   <p:input port="stylesheet">
     <p:document href="http://example.com/xsl/html.xsl"/>

 <p:count name='countstep'/>


so I would think it does one of the following;

1) output html-results which supersedes any kind of default output port

2) output both html-results and a default output named 'result' (which
is the result of processing xslt and count step)

3) do something else

I might be wrong, but I can't seem to find the explicit or implicit
words in the spec to define what behavior should happen here.


cheers, Jim Fuller
Received on Wednesday, 7 May 2008 13:14:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:25 UTC