HTTP Client binary method
Max Toro
I wanted to ask you about the binary method.
From http://www.expath.org/modules/http-client.html#d2e362 :
"Except when its attribute src is present, a http:request element can
have several attributes representing serialization parameters, as
defined in [Serialization]. This spec defines in addition the method
'binary'; in this case the body content must be either an xs:hexBinary
or an xs:base64Binary item, and no other serialization parameter can
be set besides media-type."
This means that the only way to use 'binary' is to provide an
xs:hexBinary or an xs:base64Binary item in the $bodies argument, and
cannot be used when the content is children of the http:body element,
since nodes cannot have atomic values as children. The xs:hexBinary or
xs:base64Binary item should provide the content as a byte array, thus
serialization is not needed. Please confirm if this is correct.
"The default value of the serialization method depends on the
media-type: it is 'xml' if it is an XML media type, 'html' if it is an
HTML media type, 'xhtml' if it is application/xhtml+xml, 'text' if it
is a textual media type, and 'binary' for any other case."
I don't understand the "'binary' for any other case" part. Shouldn't
'xml' be the default method, since we are dealing with nodes ?
--
Max
Michael Kay
I've implemented binary serialization in Saxon using two output methods
saxon:hexBinary and saxon:base64Binary. Like the text output method,
they only consider the text nodes and ignore all markup; unlike the text
output method, they interpret the content of the text nodes as being the
lexical representation of an octet stream in either hexBinary or
base64Binary representation.
So <xsl:result-document href="xyz.gif"
method="saxon:hexBinary">f0f0f0f0</xsl:result-document> does the right
thing.
Michael Kay
Saxonica
Max Toro
Your solution makes sense.
My main concern is with the "and 'binary' for any other case." part. If I have:
<http:body media-type="application/x-www-form-urlencoded">color=red</http:body>
...it means the text node is treated as binary. The spec explicitly
allows the implementation to use a different default method for any
other media types not covered by it, but I'm still unsure about binary
being the default.
--
Max Toro
> --
> You received this message because you are subscribed to the Google Groups
> "EXPath" group.
> To post to this group, send email to exp...@googlegroups.com.
> To unsubscribe from this group, send email to
> expath+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/expath?hl=en.
>
>
Florent Georges
Hi,
> I've implemented binary serialization in Saxon using two output
> methods saxon:hexBinary and saxon:base64Binary. Like the text
> output method, they only consider the text nodes and ignore all
> markup; unlike the text output method, they interpret the
> content of the text nodes as being the lexical representation of
> an octet stream in either hexBinary or base64Binary
> representation.
Yes, that's also what I slowly became to think. Having a single
method leads to ambiguities or to privilege one of the two XDM
binary types over the other.
More and more, I also think that this should be defined on its
own, as this is used by several modules (the HTTP Client, but also
the ZIP module, and the Webapp framework). As well as other
"standard methods", like "ser:strict-xhtml" to be equal to the
standard "xhtml" with the serialization parameters doctype-public
and doctype-system set to the correct value for the XHTML DTD
Strict and the media-type parameter set to "text/html".
Regards,
--
Florent Georges
http://fgeorges.org/
Florent Georges
Hi,
> My main concern is with the "and 'binary' for any other case."
> part. If I have:
> <http:body media-type="application/x-www-form-urlencoded">color=red</http:body>
> ...it means the text node is treated as binary. The spec
> explicitly allows the implementation to use a different default
> method for any other media types not covered by it, but I'm
> still unsure about binary being the default.
Yes, the spec is quite vague about what's a "textual type" for
instance. But I am sure we can improve the rules. Everything in
"text/" is textual, plus a couple of other (like the above one).
But if a MIME type is not known, I think this is the current
behaviour in every product: treat it as binary and don't do
anything with it except passing it as is or saving it in a file.
Maybe the spec (this one or a one dedicated to serialization
methods) should be more explicit and compehensive about those
rules?
Max Toro
Michael said "lexical representation of an octet stream".
--
Max Toro
Florent Georges
> How can we treat "color=red" as binary? It's not binary, or
> like Michael said "lexical representation of an octet stream".
Yes, I see. Actually I mixed up with parsing the response (if
the type is unknown, then return the content as binary). I think
you are right, for the serialization, that does not make sense.
I wonder whether we should stick to the XSLT behaviour (default
method is 'xml') or make the method attribute required...
Max Toro
default method.
e.g.
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml"/>
<xsl:template match="/">
<xsl:text>color=red&color=blue</xsl:text>
</xsl:template>
</xsl:stylesheet>
...produces:
<?xml version="1.0" encoding="UTF-8"?>color=red&color=blue
The xml declaration and the & entity are completly unwanted. On
the other hand, if we use the text method:
color=red&color=blue
... we get the desired result.
Maybe something like this:
1. If sequence is single xs:hexBinary or xs:base64Binary then no
serialization is needed, and serialization parameters are not allowed,
end.
2. Sequence goes through sequence normalization (
http://www.w3.org/TR/xslt-xquery-serialization/#serdm )
3. If method is specified then honor that, else if document node
contains single text node then use 'text', else use 'xml'.
--
Max Toro
Florent Georges
> Maybe something like this:
> 1. If sequence is single xs:hexBinary or xs:base64Binary then
> no serialization is needed, and serialization parameters are
> not allowed, end.
> 2. Sequence goes through sequence normalization (
> http://www.w3.org/TR/xslt-xquery-serialization/#serdm )
> 3. If method is specified then honor that, else if document
> node contains single text node then use 'text', else use 'xml'.
Well, that makes the *default value* of the method parameter
quite complex, and complex default values are usually more
confusing than helpful. Besides 3. differs from the existing
XSLT rule for the default value (which is 'xml'). And 1. does
treat differently content passed as parameter or embedded within
the http:request object.
So I think the options here are really: either get the same
default value as XSLT (we are in the XML world, so 'xml' makes
sense) or require an explicit serialization method...