[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RFC : XML representation of a HTTP request

Subject: Re: RFC : XML representation of a HTTP request
From: "Robert Hanson" <robertha@xxxxxxxxxx>
Date: Fri, 21 Jan 2000 09:58:29 -0500
xml request variable
I'm not too sure I understand why you chose a structure like that.  My feeling
is that the request method is no more a variable than the host name is... to
me, both of these are header information.  And for the parameters, you seem to
be assuming that they are variables of some sort.  What if the parameters are
a single XML document sent in an HTTP POST like XML-RPC uses?  Although in the
situation you are talking about, I don't see that this would be a problem.

Here is the way I would do it:

 <request>
   <standard-headers>
     <accept-charsets>
        <accept-charset>iso-8859-1</accept-charset>
        <accept-charset>UTF-8</accept-charset>
    </accept-charsets>
     <accept-language>en</accept-language>
     <host>xmlbinder</host>
     <request-method>GET</request-method>
     <uri>/result-tree/example.xml</uri>
     <script-name>/xmlbind/XSLServlet</script-name>

    <cookies>
        <cookie>
            <name>Apache</name>
            <value>192.127.127.3.2835094787032722</value>
        </cookie>
    </cookies>
     .../...
   </standard-headers>
   <other-headers>
        <header>
            <name>SOAPMethodName</name>
            <value>Some-Namespace-URI#GetLastTradePrice</value>
        <header>
     .../...
   </other-headers>
   <parameters>
     <parameter>
        <name>x</name>
        <value>2</value>
     </parameter>
     <parameter>
        <name>y</name>
        <value>3</value>
     </parameter>
   </parameters>
 </request>

This would give you the standard HTTP headers in the standard-headers section,
with the cookies broken down to name value pairs.  Under other-headers,
non-standard HTTP headers can be put there.

Parameters can stay the same as long as you are sure that they will always be
name-value pairs and not some other type of content... although I changed the
way it is broken down.  The reason I did it that way is because first of all,
I don't like using tag names to represent variables.  Secondly, I tend to stay
away from using attributes unless there is a good reason for it, like an ID
attribute, or using it to hide the data from a browser (like RDF does).

I also broke down the accept-charset so that it separates the different
sets... I find that I like to have the separate bits of information separated,
which makes it a little harder to go from HTTP request to XML, but once in XML
it is easier to identify small pieces of information without have to parse the
character data in the XML as well.

I hope this is what you were looking for.

All the best.

Robert

----- Original Message -----
From: Eric van der Vlist <vdv@xxxxxxxxxxxx>


> Hi,
>
> In a java servlet environment, I have developed a mapping of the HTTP
> request into a result tree fragment through sax events (using XT).
>
> The goal is to use this environment in a XSL transformation to trigger
> context dependent actions and transformation.
>
> I'd like to have your feedback on the structure I am proposing...
>
> Currently, this structure of the tree is something which, translated
> into XML, would be like :
>
> <request>
>   <headers>
>     <accept-charset>iso-8859-1,*,utf-8</accept-charset>
>     <accept-language>en</accept-language>
>     <host>xmlbinder</host>
>     <cookie>Apache=192.127.127.3.2835094787032722</cookie>
>     .../...
>   </headers>
>   <variables>
>     <REQUEST_METHOD>GET<REQUEST_METHOD>
>     <URI>/result-tree/example.xml</URI>
>     <SCRIPT_NAME>/xmlbind/XSLServlet</SCRIPT_NAME>
>     .../...
>   </variables>
>   <parameters>
>     <x>2</x>
>     <y>3</y>
>   </parameters>
> </request>
>
> (It could be extended to the cookies as well.)
>
> The names of the headers, variables or parameters is used as the name of
> the entities.
>
> In this tree, the path to the variable "URI" is therefore :
> "/request/variables/URI".
>
> Would it be better to have a common entity name and something like :
>
>        <parameter name="x">2</parameter>
>
> The path to the variable "URI" would then be  :
> "/request/variables/variable[@name='URI']".
>
> If it's the case and if we have different entity names for the
> parameters, headers, variables (and later on cookies), do we need to
> keep a structured path to these different entities since a path of
> "/request/variable[@name='URI']" would already be sufficient to
> differentiate the variable "URI" from a possible parameter "URI" ?
>
> And of course, If I am reinventing the wheel and if a XML schema to
> represent a request context has already been defined, I'll be very glad
> to know it !
>
> Related links :
>
> http://downloads.dyomedea.com/java/examples/xslservlet/result-tree/
> (the example with its code)
>
> http://www.egroups.com/group/xml-tips/info.html
> (newly created discussion list for these "tips")
>
>
> Thanks for your feedback.
>
> Eric



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.