General remarks on Annex A (very big mail, sorry for that)

Dear,

Sorry for the big list, but I didn't find the time to split it in 30
mails or so....

----

General remarks on the spec related to this part

The spec is still speaking (and I think it is a good point) of
definition of default input port and default output port

[[
Each step may have a default output port. [Definition: If a step has
exactly one output port, or if one of its output ports is explicitly
designated as the default, then that output port is the default output
port of the step.] If a step has more than one output port and none is
explicitly designated the default, then the default output port of
that step is undefined.
]]

So i'm proposing to be clear for step with multiple input or output



General remarks on the component

Please remove sequence="no" everywhere since it is confusing


A.1.1 Count

Can we remove the [Proposed] status ?

A.1.2 Delete

I'm ok with match semantics here

A.1.3 Equal

I'm relunctant to see direct refereance to XPath 2.0. I would feel
better it was just a copy/paste of what we need

I'm not sure it would be simple to compare to sequence of document (if
someone has clear idea on how to do that with current components...)

Do we want  <p:input port="source"/> to be the default ? or no default ?

A 1.4 Error

Here is the definition of the error content
E.2 err:error

Each specific error is represented by an err:error element:

<err:error
  name? = NCName
  type? = QName
  code? = QName
  href? = anyURI
  line? = integer
  column? = integer
  offset? = integer>
   (anyElement*)
</err:error>

We should provide all the attribute to be in synch with

Since we allow error to have any content, I propose to be able to give
a content input with such content if necessary

It is not clear what the rules are for such limitation ?

How is the name computed ?


A.1.5 Escape Markup

Wasn't there a time where a match pattern was proposed ?
If not, I wouldn't mind since we should be able to do that through a
p:viewport step


A.1.6 Identity

Ok

A.1.7 Insert

I still don't know why we limit ourselves to a match pattern here ?
May be at this point the match pattern **allow** nested visiting ? If
so, please make it clearer
I would mind for this one, since we don't have recursion in XProc

Do we want  <p:input port="source"/> to be default or no default ?

A.1.8 Label Elements

I think that it was discussed to allow a select attribute here to say
which elements are concerned. Please add it

I would also mind for this one, since we cannot be sure with the use
of viewport to have an xml:id-valid document when concatenating it
back

Trough reading. Apart from p:label that should enforce xml:id rules
(NCName and unique), we don't have any component that is xml:id aware,
do we ?

A.1.9 Load

Please rename validate to dtd-validate (to avoid confusion)
It is not clear wether an error will be throw if external document are
not accessible
I think we should add xmlid-validate too

A.1.10 Namespace Rename

It is clear that @from is a *list* of namespace
But it is not clear for @to : is it also a list (à la translate) ? or
a single destination ?
what if we have empty list in @from ?
what if we have empty string in @to ?
what if we use http://www.w3.org/XML/1998/namespace in @from ? in @to ?


What kind of error such a component can throw ?

A.1.11 Parameters

No comment for the moment (I wait for stabilisation of parameter proposal)

A.1.12 Rename

The first sentence contradict the second

1st : "The rename step renames elements or attributes in a document"
2nd : "Each element, attribute, or processing-instruction matched by
the match pattern"


Same as match in Insert
Can we make available the current matched node to the evaluation of
@name option (as in String Replace) ?

A.1.13 Replace

I have a strong use case, where I want to replace a PI with the
content of a document
Can we allow matching of PI, too ? (and even comment() ?)

Do we want <p:input port="source"/> to be the default or no default ?


A.1.14 Set Attributes

Tricky case : what about

<p:set-attributes match="*">
  <p:input port="attributes">
    <p:inline>
      <root xml:id="fixed" xmlns:toto="http://mynamespace" />
    </p:inline>
 </p:input>
</p:set-attributes>

Do we want <p:input port="source"/> to be the default or no default ?


A.1.15 Split Sequence

Do we want <p:output port="matched" sequence="yes"/> to be the default
or no default output ?


A.1.16 String Replace

The first sentence is confusing
"The String Replace step matches a set of nodes in the document
provided on the source input port and replaces them with a new
generated string"

please replace by something like
"The String Replace step matches a set of nodes in the document
provided on the source input port and replace each matched node with a
new generated string"

A.1.17 Store

This sentence is not clear
"The output of this step is a document containing a single c:result
element whose href attribute contains the same value as the href
option."

I'm still unclear by this one and hope to have a clear idea of
serialisation stuff before last call

A.1.18 Unescape Markup

"The Unescape Markup step takes the text value of the document element
and parses the content as if it was and unicode character stream
containing XML"
s/and unicode/a unicode/
"This is the reverse of the serialize step." --> "This is the reverse
of the Escape Markup step"


A.1.19 Unwrap
Please make clear that this match pattern works with nested matches

What is the expect result of
<p:unwrap match="*/*" />

A.1.20 Wrap

"The is processed by" --> "The document is processed by"

We should put the discussion back on telcon for allowing group-adjacent

A.1.21 Wrap Sequence

The text is very confusing
[[
The Wrap Sequence step converts the sequence of documents on the
source port into a single document and produces a single document on
the result port. The document produced has a new document element
whose name is specified via the wrapper option and whose children are
the documents in the order recieved on source port. Each document
received is converted into a sequence of children by taking the
children of the document info item.
]]
Is something like this more in line with the proposed behavior ?
[[
The Wrap Sequence step converts the sequence of documents on the
source port into a single document which is produced on the result
port. The document produced has a new document element whose name is
specified via the wrapper option and whose children are the documents
in the order recieved on source port.
]]

Having say that

What happen to PIs, spaces and comments outside the document node ?

We should also consider having a group-by option on this one

A.1.22 XInclude

I think we never solved the p:map proposal for this one ?

A.1.23 XSLT

Do we want <p:input port="source"/> to be the default or no default ?
I think having a verb "transform" instead of a name
"source/result/alternate/insertion/replacement/attributes/matched/notmatched"
is very confusing

I prefer to have a name and "stylesheet" would fit perfectly

A.2.1 HTTP Request

Norm's proposal seem to lead to consensus, please use it instead

A.2.2 Relax NG Validate

Do we want <p:input port="source"/> to be the default or no default ?
Is there really no options ?

A.2.3 XML Schema Validate

Do we want <p:input port="source"/> to be the default or no default ?
Please detail the expected behavior of the use of option (I'm unclear
with assert-valid and the allowed value for mode)

A.2.4 XSLT 2.0

Do we want <p:input port="source"/> to be the default input or no
default input ?
I prefer to have a name (instead of a verb) and "stylesheet" would fit perfectly
Do we want <p:input port="result"/> to be the default output or no
default output ?

A.2.6 XQuery 1.0

Do we want <p:input port="source"/> to be the default input or no
default input ?

Are we sure to not have any troubles with such a transformation of the query ?

Mohamed

-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Saturday, 23 June 2007 11:56:45 UTC