RE: Bridging XML/HTTP

> 
> That's what I was talking about, though you appear to want to take it
> further.  But I'm not sure how far it could be taken.  A document as
> a representation of a resource doesn't know whether its coming or
> going, for example.  I'm quite certain that the best place for that
> information isn't in the document.  That feels more like a workflow
> solution to me, if I understand you correctly.

I think of the 'document' as a reflection of the resource, rather than as a
file on disk. 
Not sure if that's how you view it (& I'm not sure if this even makes
sense.)
So, the document is 'acquired' and the way it is acquired can describe
whether it is coming or going.

Also, you can use XLink type of stuff for the meta info to be outside of
media:
<output>
 <http:Headers>
	<http:Content-Type>text/plain</http:Content-Type>
 </http:Headers>
 <!-- NOTE: This is not real XLink... -->
 <body xml:link='simple' href='path/to/some.txt' /> 
</output>

> 
> > In interesting by-product/experiment would be to have a 
> listener on port 80
> > parse the incoming text & generate (constrained by the HTTP
> > DTD/schema/structure/etc) either a) SAX events b) XML text 
> or c) virtual
> > DOM. In this experiment, you could then use generic XML 
> processors (XSL
> > engines, utilities, etc) to handle HTTP requests.
> 
> Yup.  I'm not sure what this would buy you though.  Is there
> something you can do (or do better) with this approach?
> I agree that it's interesting to think about.
> 

I was thinking of how hard it was to do some things with XSL. For example,
there is no way to touch the response headers. The body of the XSL file
describes the response entity body - where do you say what the Content-Type
header is? Possibly in processing instructions... I don't know.

So I was trying to come up with a mechanism where the full capabilities of a
Web application could be implemented with XSL.

If you had a 'hub' document which linked to four XML documents (request,
response, session, application) you could start processing the hub document
& read from the request, go to the specified target in the application
data-space (exposed as XML), do conditional things based on the session (who
the user is, etc) and fill out the response (if the XSL author knew the
output schema was full HTTP with embedded HTML and not just HTML, they could
output the headers, etc. - but this is still fuzzy in my mind - still an
experiment.)

Mike


> -----Original Message-----
> From: Mark Baker [mailto:mark.baker@Canada.Sun.COM]
> Sent: Monday, March 27, 2000 1:18 PM
> To: Mike Dierken
> Subject: Re: Bridging XML/HTTP
> 
> 
> Mike Dierken wrote:
> > 
> > I'm not talking about changing HTTP - I'm talking about 
> expressing existing
> > HTTP data structures   via XML.
> 
> Ah, sorry.
> 
> > 
> > For example, the Java Servlet API is an object model of 
> what HTTP provides -
> > a structure & API for reading & writing. The API constrains 
> what you are
> > allowed to write.
> > If there were an XML model of what kinds of things are allowed to be
> > written, that becomes a declarative definition of those constraints.
> > Declarative data could then be embedded in content & a 
> processor could
> > easily extract and translate to HTTP. This XML processor is 
> some of what a
> > web server does - it looks inside HTML content for certain 
> tags & translates
> > to HTTP output.
> 
> That's what I was talking about, though you appear to want to take it
> further.  But I'm not sure how far it could be taken.  A document as
> a representation of a resource doesn't know whether its coming or
> going, for example.  I'm quite certain that the best place for that
> information isn't in the document.  That feels more like a workflow
> solution to me, if I understand you correctly.
> 
> > In interesting by-product/experiment would be to have a 
> listener on port 80
> > parse the incoming text & generate (constrained by the HTTP
> > DTD/schema/structure/etc) either a) SAX events b) XML text 
> or c) virtual
> > DOM. In this experiment, you could then use generic XML 
> processors (XSL
> > engines, utilities, etc) to handle HTTP requests.
> 
> Yup.  I'm not sure what this would buy you though.  Is there
> something you can do (or do better) with this approach?
> I agree that it's interesting to think about.
> 
> MB
>

Received on Monday, 27 March 2000 16:40:14 UTC