- From: Innovimax SARL <innovimax@gmail.com>
- Date: Sat, 23 Jun 2007 13:56:42 +0200
- To: "XProc WG" <public-xml-processing-model-wg@w3.org>
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