- From: Toman, Vojtech <vojtech.toman@emc.com>
- Date: Wed, 2 Oct 2013 10:57:09 -0400
- To: "public-xml-processing-model-comments@w3.org" <public-xml-processing-model-comments@w3.org>
> Indeed. Though we can use the feature on steps like p:count so it won't > be that obscure. And it only applies to steps that take sequences on > input. > > ordered=false: > p:count > p:sink > p:split-sequence > p:wrap-sequence > p:xslt > p:exec > p:xquery > > ordered=true: > p:identity > p:insert > p:pack > > ordered=i'm not sure: > p:validate-with-xml-schema I don't know. My feeling is that I would prefer to have everything ordered (or everything unordered) by default and give people the ability to change that where they need to. There is a difference between specifying the "ordered" flag on the step declaration (on the input/output port level, I presume) and when you actually invoke the step (that is, when you specify the bindings). We can think about which way to go, but my worry is that explicitly saying in the spec that some input/output ports of the standard steps are unordered and some are ordered might end up a similar success as our decision to give some of the steps a single non-primary output port. Also, currently our options/variables are strings, but if we allow them to be bound to sequences, we should think about what to say about the connections of p:option/p:variable/p:with-param and maybe also p:choose/p:xpath-context (and other places where XPath is involved). Regards, Vojtech -- Vojtech Toman Consultant Software Engineer EMC | Information Intelligence Group vojtech.toman@emc.com http://developer.emc.com/xmltech
Received on Wednesday, 2 October 2013 14:57:55 UTC