Re: HTTP client module

John Snelson wrote:
> M. David Peterson wrote:

  Hi,

  I tried to not repeat what I already told in previous emails,
to not obfuscate the discussion.

> >     3) What is the use case for send-authorization? Why not
> >     just send authorization in the first request?

> [...]

> I would imagine that if the user requests authentication, it
> would be more efficient to send the authorization credentials
> in the first request.

  I do too.  I asked on the XProc-dev list for a use case.

> Now xml has two well known media types ("text/xml"
> and "application/xml"), but there are a number of media types
> that use XML but might not be considered "xml" media
> types ("application/rdf+xml", for instance).

  I think it is, per RFC 3023, but I have to clarify that, thanks
for pointing this out.

|> [ ... about lazy evaluating item returned after http:request,
|>   representing the entity body of each message's part ... ]

> In that case, lazy evaluation should be sufficient for
> efficiency.  Results that aren't needed won't be evaluated.

  As I said, I do not think it is reasonable to rely on lazy
evaluation while defining an *extension* function.  If there is a
reason to take optimization into account at one point, I don't
think we can just rely on lazy evaluation.

  That's just my impression.  Is it possible in XQilla?  Any
other implementer about this?

> Can you point to a specification where a "textual media type"
> is defined?  If not, then this specification needs to define
> it.  My thoughts were that the most obvious definition would be
> a media type that started with "text" - but then what
> about "text/xml".

  Yes, I think you're right: I should define it more precisely.
As a first clue, I would say: "media type of main type 'text/'
except those defined otherwise" (for instance text/xml in RFC
3023.)


> I think you misunderstand - I'm wondering if it should be
> changed to be optional. My thoughts are that that HTML parsing
> into an XML infoset is a subjective process, and libraries to
> do such things might not always be available.

  At a first glance, http://tidy.sourceforge.net/ lists the
following languages: C, Java, Perl, Python, C++, .Net,
Delphi/Object Pascal, PHP.  So I guess that should be ok for
existing XSLT 2.0 and XQuery implementations.

> I do think it's very useful functionality, though.

  Yes, and a common use case.  That's why I chose this way.  If
you want HTML as text, you can set override-content-type to
text/plain.  The alternative would be to return HTML as text and
rely on another extension, xx:parse-html().

  But then, we could do the same with XML: returning it as text
and let the user using xx:parse-xml()...

  That would simplify the http:send-request() specification.  But
I think that would reduce its usability too, without really
supporting new use cases.  But I can be wrong, of course.

> No. I want the ability to return an XML representation of JSON
> if the mime type is "application/json", for instance.

  I see.  I think this is really behind the scope of this
extension.  I guess one can create a library of XPath functions
to parse JSON as a string and return a corresponding XML
representation (for some definition of 'corresponding'.)  Then
you can use the HTTP response on the one hand and this library on
the other hand and get the result you want.

> My understanding is that "override-content-type" will only
> allow me to tell the implementation to treat (for instance) a
> response with mime type "image/jpeg" as "application/xml" and
> try to parse it.  That sounds dangerous to me, so I'd like a
> good use case for having the functionality.

  Sure, trying to parse an image as XML is dangerous.  Unless you
know for sure that the server is wrong and the content *is* XML.

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/