- From: James Fuller <james.fuller.2007@gmail.com>
- Date: Thu, 21 Aug 2008 14:25:08 +0200
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
On Thu, Aug 21, 2008 at 1:55 PM, Norman Walsh <ndw@nwalsh.com> wrote: > / James Fuller <james.fuller.2007@gmail.com> was heard to say: > | ------------------------------------ > | > | in section 3 Syntax Overview > | > | 'Six kinds of things are named in XProc:' > | > | propose refining to > | > | 'There are six kinds of entities defined in XProc' > | > | named implies that they have a @name attribute, where as 'things' is a > | bit of a wholly term > > Yeah, but entities has baggage too in the XML world.. Anyone got > another suggestion? constituents, components, items ... > | minor nit with p:variable > | > | in section 2.1 Steps subpipeline is defined to take a top level p:variable > | > | subpipeline = p:variable*, > | (p:for-each|p:viewport|p:choose|p:group|p:try|p:standard-step|pfx:user-pipeline)+ > | > | furthermore p:choose and p:try can also have a top level p:variable > | defined ... should we harmonize this usage of p:variable > | and allow outside of nested subpipeline on p:for-each, p:viewport, and > | p:group elements as well ? > > To what end? The only reason p:variable is called out explicitly in > p:choose and p:try is because those steps don't directly contain > subpipelines. ok I understand this now (after implementing it) > | should we add some concept of http timeout on c:request ? perhaps as > | an optional option > > Perhaps. thx for considering > | same thing goes for proxy > > You mean a way of specifiying a proxy? I think that belongs at the > application or even OS level, not in the pipeline. it does, but there maybe scenarios where you would like to configure everything from within xproc ... and configure proxy explicitly > | also, I did not see any discussion, but I may have missed it .... did > | the WG consider any need for an HTTP_REFERER type element in > | c:response ? I would propose adding it to the c:http-response element > | as an attribute. > > It's a header, isn't it? So you can get it back if you ask for the > details and you can pass it in if you wish. Or am I totally confused? get back to you on this one, need to remind myself just what I was highlighting > | in section 7.1.15 p:namespace-rename > | > | this step has always seemed to me slightly incorrect, e.g. the > | operation that is occuring is more appropriately called > | namespace-mapping ... I prefer how XSLT 2.0 approaches this using > | namespace-alias function ... below is a rough translation of what this > | would look like in XProc > | > | <p:namespace-alias xmlns:old="http://someold.com/namespace" > | xmlns:new="somenew.com/namespace"> > | <p:option name="literalNS" value="old"/> > | <p:option name="targetNS" value="new"/> > | </p:namespace-alias> > | > | I think its pretty clear and would propose we add to steps (and remove > | namespace-rename) > > That seems like a pretty significant design change for what my > experience suggests is a very, very small edge case. In my decade or > so of XSLT use, I think I've used namespace aliasing just about twice. > I think we have to provide a step to do it, but I don't think we have > to work hard to make it easy. agreed. ta, J > > Be seeing you, > norm > > -- > Norman Walsh <ndw@nwalsh.com> | Most human beings have an almost > http://nwalsh.com/ | infinite capacity for taking things for > | granted.--Aldous Huxley >
Received on Thursday, 21 August 2008 12:25:47 UTC