Re: Allowing for naive/simple p:http-request

/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| I think Murray is right in many sense
|
| 1) we need to be consistent on the use of "load-like" component

I think our consistent story should be "use XML". There are, at the
moment, only two places where it seems to me that we might want to
make special rules for supporting HTML content: in http-request
(because the pipeline author has essentially no control over what
comes back) and in unescape-markup (because it's broken by design).

If we can't draw a relatively small, clear boundary around the areas
where we're going to provide special support, then I'll probably feel
better if we don't do anything at all.

| 2)...but we need to take care, that the user should be able to know
| that the input was "changed" to be processed

I don't really understand this concern. We're only making the changes
that the user requests. If they don't request any, we won't make any.

1. User runs unescape markup without asking for special support.
   a. The escaped markup is WF XML, life is good
   b. The escaped markup is not WF XML, step fails

2. User runs unescape markup and *asks for* special support.
   a. The escaped markup is WF XML, life is good
   b. The escaped markup is not WF XML, step fixes it so it's WF XML

Likewise,

3. User runs http-request without asking for special support.
   a. What comes back is WF XML, life is good
   b. What comes back is not WF XML, step fails

4. User runs http-request and *asks for* special support.
   a. What comes back is WF XML, life is good
   b. What comes back is not WF XML, step fixes it so it's WF XML

I think that pipeline authors in the 2b and 4b cases are *very
unlikely* to ever care that the markup was "fixed" for them. That's
what they asked for.

But they can find out, if they want. In 2b, they can run the unescape
step in a try/catch. In 4b, they can either run the step in a
try/catch or they can examine the content type sent back to them. If
we adopt Henry's simpler version of http-request as an alternative
form, then they can't tell. So they shouldn't use that form if they
care.

| With this respect we have several points to look at :
| * if we don't mandate load, be sure file:// is mandate on http-request

We have a load step, I don't think that's going away. We're not
offering any special support for HTML on the load step. I don't see
any reason to mandate file:// on the http-request step.

If you have a bag of not-WF XML bits on your local disk and you want
to run a pipeline over it, fix it. Or use some implementation-defined
step that can load bags of bits and produce XML.

| * if we allow it on load, we need to be sure that load would give
| extra information to the user if needed

I don't want to support anything special on load.

My feeling is, if we support HTML on load, we'll have to support it on
p:document. If we support HTML on load and document and unescape
markup and http-request, why not support it on every step? If we
support not WF XML on every step, how is this an XML pipeline
language?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | No man's knowledge here can go beyond
http://nwalsh.com/            | his experience.--John Locke