W3C home > Mailing lists > Public > www-tag@w3.org > May 2006

Re: Moving forward on Site Metadata [siteData-36]

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Mon, 8 May 2006 11:09:49 -0700
Message-Id: <DFEA1DEC-75CC-4094-9966-6898F95FF887@yahoo-inc.com>
Cc: www-tag@w3.org
To: Dan Connolly <connolly@w3.org>


On 2006/05/05, at 3:06 PM, Dan Connolly wrote:
>
> Tim suggested again using an HTTP header pointing to some
> site metadata in RDF... I see pretty much the same suggestion
> in the Jan 2004 meeting record.
>
> Using the favico use case, I think the idea is something
> like:
>
> C->S:
> 	GET /some/page HTTP/1.1
> 	Host: www.foo.org
>
> S->C:
> 	200 OK
> 	Link: rel="meta" </sitedescr>
>
> And in /sitedescr we'd have something like
>
>   <http://www.foo.org/sitedescr#thisSite>
>     urispace:prefix "http://www.foo.org";
>     chrome:icon <http://www.foo.org/icons/site_icon>.

Is the value of link/@rel="meta" contrained (e.g., it's invariant  
across a site)?

BTW, it is possible to use OPTIONS in combination with content  
negotiation on Apache; it's surprisingly easy -- just a simple  
rewrite rule.

localhost:~> telnet www.mnot.net 80
Trying 216.92.32.220...
Connected to mnot.net.
Escape character is '^]'.
OPTIONS / HTTP/1.1
Host: www.mnot.net
Accept: text/robots

HTTP/1.1 303 See Other
Date: Mon, 08 May 2006 18:08:07 GMT
Server: Apache/1.3.29
Location: http://www.mnot.net/robots.txt
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

e9
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>303 See Other</TITLE>
</HEAD><BODY>
<H1>See Other</H1>
The answer to your request is located <A HREF="http://www.mnot.net/ 
robots.txt">here</A>.<P>
</BODY></HTML>

0

>> I ask because it's getting quite relevant; e.g., there is a Task
>> Force that's looking at mechanisms for cross-site access control
>> <http://lists.w3.org/Archives/Member/member-accesscontrol-tf/>, and a
>> site metadata format is one potential solution.
>
> Yes... has anybody sketched that out in any detail?
>
> (the tf seems to have member-confidential proceedings, which
> makes collaboration with www-tag awkward.)

I'll bring it up with them.


>>  Additionally,
>> individual groups, sites and services continue to develop ad hoc site
>> metadata formats. Combined with the growing popularity of
>> microformats, service description, etc., I suspect Web metadata is
>> about to become a lot more useful and prevalent, and site metadata is
>> part of that.
>
> You're dangerously close to volunteering to do my action for me ;-)

I'm happy to give it a shot.

> I like the idea of being able to declare icons, access control,
> etc. by URI prefix.
>
> I guess it doesn't allow for the *.foo.com pattern currently
> covered by the <?access-control ?> PI.
>
> I'll have to take another look at
>   http://www.w3.org/TR/urispace.html
>
> There's also the cwm/N3 mechanisms of log:uri combined
> with str:startsWith and str:matches (regex matching). Prolly
> better to use the more standard XQuery/XPath string manipulation
> library; I suspect the overlap is around 95%.

Agreed. I think there are two problems; scope of discovery (e.g., can  
a UA that has found the policy for http://www.example.com/foo know  
that they also have the policy for http://www.example.com/bar) and  
scope of application (how expressive the language is). They're  
related but slightly different.

> As I understand it, in the javascript access control case,
> the sandbox in the client is trusted to fetch the data and
> decide after it comes back whether to let the hosted javascript
> app see it.

For GET, yes; for POST, PUT or any other unsafe method, it's not so  
clear.

--
Mark Nottingham
mnot@yahoo-inc.com
Received on Monday, 8 May 2006 18:12:41 GMT

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