W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

Re: New question: distinguished status of http:?

From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Date: Fri, 1 Mar 2002 10:15:28 -0500
Message-Id: <p04330105b8a54948e414@[192.168.254.4]>
To: Patrick Stickler <patrick.stickler@nokia.com>, WWW TAG <www-tag@w3.org>
At 7:03 PM +0100 2/28/02, Patrick Stickler wrote:


>Hmmmm... this seems to suggest to me that there would be utility in a
>standardized means by which applications could obtain knowledge about what
>URI schemes mean, in some standardized manner and according to some
>standardized ontologies, to determine what is expected of them.
>

This reminds me of Java protocol handlers. Of course, protocol handlers:

1. Were specific to Java
2. Never really worked in the first place

>Would not the Semantic Web offer a means of extensibility for
>URI scheme semantics so that agents need not know, as part of their
>static design, about all possible URI schemes?
>
>We provide auxiliary, supporting knowledge for XML instances that
>say how to validate them, display them, transform them, etc. so that
>applications need not understand natively what the significance
>of particular markup vocabularies are. Why then would it be
>unreasonable to provide auxiliary knowledge about URI schemes so that
>applications could be similarly informed about what a given URI means,
>even if it has never seen one of that scheme before?
>

This is a very interesting idea. If this could be defined through an 
XML description of the protocol, as opposed to compiled code, then it 
might succeed where protocol handlers failed. As a proof of concept I 
wonder if it's possible to design an XML format sufficiently general 
that it could describe all the information that a single client would 
need to implement the following used but widely diverse protocols:

1. http  (TCP, request-response, single socket)
2. ftp  (TCP, multiple sockets, bidirectional, client and server)
3. telnet (TCP, interactive, user input required after connection)
4. mailto  (TCP, interactive, user input required before connection)
5. rtspu (UDP)
6. file  (no sockets at all)

That's a pretty diverse batch. If you can cover those six, I'd be 
willing to bet you could cover most other URLs and probably URIs too. 
However, remember that for this to work the client would have to have 
no preexisting knowledge of any of the protocols.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+
Received on Friday, 1 March 2002 10:20:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:05 GMT