some comments onMay 1st draft

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.'

   to

''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:input>
 </p:xslt>

 <p:count name='countstep'/>

</p:for-each>

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:output>

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

 <p:count name='countstep'/>

</p:for-each>

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