W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > August 2008

Re: more comments on latest xproc II

From: James Fuller <james.fuller.2007@gmail.com>
Date: Thu, 21 Aug 2008 14:25:08 +0200
Message-ID: <a0ad8ffe0808210525t25fd7f44k79ea28acea6e21d8@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 21 August 2008 12:25:47 GMT