- From: Norman Walsh <ndw@nwalsh.com>
- Date: Mon, 25 Jun 2007 10:34:37 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87vedcgl1e.fsf@nwalsh.com>
/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| General remarks on the spec related to this part
Thanks, Mohamed! Comments inline. (Including some questions for the
WG, so read on, everyone :-)
| 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
What needs to be clarified?
| General remarks on the component
|
| Please remove sequence="no" everywhere since it is confusing
Done.
| A.1.1 Count
|
| Can we remove the [Proposed] status ?
Done.
| A.1.2 Delete
|
| I'm ok with match semantics here
Yes, clearly either match or select work for delete. My only concern
is that delete, insert, and rename all use *the same* option.
| 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
Yuck! That means we have to track errata, etc. Duplication of
information is bad :-)
| 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...)
We don't allow a sequence of documents on either of the p:equal step's
ports. So, looking at the text of fn:deep-equal, it seems to me that
This function assesses whether two sequences are deep-equal to each
other. To be deep-equal, they must contain items that are pairwise
deep-equal; and for two items to be deep-equal, they must either be
atomic values that compare equal, or nodes of the same kind, with
the same name, whose children are deep-equal.
works just fine. In our case, the two sequences that will be compared
each contain exactly one document item. It follows that they are deep
equal if and only if their children are deep-equal. Comparing a
sequence of elements is a requirement for the function, so it all
"just works".
Am I overlooking something?
| Do we want <p:input port="source"/> to be the default ? or no default ?
Our spec currently allows any (and all) input ports to be defaulted. I
don't think we want to special case that or p:equal. (Or any of the
other components.)
| 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 ?
I'm sorry, I don't understand your questions. All of the attributes are
optional and you can put any content you want inside err:error. I guess
that should really be (anyElement|text)*
| 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
Alex?
| 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
What do folks think?
| 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
Ok.
| 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 ?
No, I don't think so. But we don't have any other steps that care about
IDs either.
| A.1.9 Load
|
| Please rename validate to dtd-validate (to avoid confusion)
That seems sort of clumsy to me. Anyone else have an opinions?
| It is not clear wether an error will be throw if external document are
| not accessible
I believe a validating parser must fail if it can't load the external
subset.
| I think we should add xmlid-validate too
Hmm. Opinions?
| A.1.10 Namespace Rename
|
| It is clear that @from is a *list* of namespace
I think that's a mistake. I think it should be a single namespace.
| But it is not clear for @to : is it also a list (à la translate) ? or
| a single destination ?
Which resolves that question
| what if we have empty list in @from ?
and allows an empty 'from' to mean the 'null' namespace.
| what if we have empty string in @to ?
I think that deletes the namespace.
| what if we use http://www.w3.org/XML/1998/namespace in @from ? in @to ?
that should be an error, as should the XMLNS namespace.
| What kind of error such a component can throw ?
I think it can only fail if the XML or XMLNS namespace is specified.
| A.1.11 Parameters
|
| No comment for the moment (I wait for stabilisation of parameter proposal)
Heh.
| 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) ?
The value of the name attribute is a string in this case, not an
expression, so I don't think that makes sense. We could make the value
an expression, but what would the use case be?
| 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() ?)
Yes, I think so.
| 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>
I think that produces an xml:id invalid document. I don't think the
toto namespace comes into play.
| A.1.15 Split Sequence
|
| Do we want <p:output port="matched" sequence="yes"/> to be the default
| or no default output ?
Yes, I think the matched port should be the 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"
I think I improved that.
| 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
We must have a clear understanding of the serialization 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"
Fixed.
| A.1.19 Unwrap
| Please make clear that this match pattern works with nested matches
Is that what we want?
| What is the expect result of
| <p:unwrap match="*/*" />
Depends on how we answer the preceding question :-)
I think I had in mind that in all cases were we use a match pattern,
we don't recurse into the matched content. But I could be confused :-)
| 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
Right.
| 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.
| ]]
I think I improved the text.
| 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
That seems like overkill to me.
| A.1.22 XInclude
|
| I think we never solved the p:map proposal for this one ?
Right. I'll put it back on the agenda, but I've given up.
| A.1.23 XSLT
|
| 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
Yes! Done.
| A.2.1 HTTP Request
|
| Norm's proposal seem to lead to consensus, please use it instead
Alex has done the lion's share of the work on this one, I'm going to
leave it to him to edit.
| 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 ?
I think we do need an option for the DTD compatibility annotations.
| A.2.3 XML Schema Validate
|
| Please detail the expected behavior of the use of option (I'm unclear
| with assert-valid and the allowed value for mode)
XSD schema experts, help, please.
| A.2.4 XSLT 2.0
|
| I prefer to have a name (instead of a verb) and "stylesheet" would fit perfectly
Yes!
| Do we want <p:output port="result"/> to be the default output or no
| default output ?
I think we want the result output to be the default.
| A.2.6 XQuery 1.0
|
| Are we sure to not have any troubles with such a transformation of the query ?
I dunno.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | A proof tells us where to concentrate
http://nwalsh.com/ | our doubts.-- Anonymous
Received on Monday, 25 June 2007 14:34:49 UTC