On 6 Jul 2006, at 15:38, Bill de hÓra wrote:
Henry Story wrote:
On 6 Jul 2006, at 06:32, James M Snell wrote:
Joe Gregorio wrote:
[snip]
7.1 Should we have language-aware titles in app:collection?
7.2.2.1
says that @title is language sensitive. I guess you may use
xml:lang,
but what about multiple language versions of the title.
Bah, you're right, @title should be an element not an attribute
and we should allow mulitple child elements as long as none
of them have the same xml:lang value. Good catch.
+1. However, IMHO, making this kind of change would make obvious the
need to have some means of uniquely identifying a collection
within the
introspection document. I'm not convinced that the href is good
enough.
(yes, I know this has been discussed before, but I don't believe
we ever
adequately resolved it).
As mentioned in a different thread here recently (sorry for being
a little indelicate there - it was very hot and moist here
yesterday), I think the spec would get out of the door fastest if
the <service> document is removed from the spec completely. If
something like this is really needed it can always be defined in a
different spec. The protocol spec should narrow its focus on
protocol issues as much as possible. A new document is not needed
to get the work done.
I filed a pace for titles. If that gets accepted, I'd like to look
at edit distance between gdata, introspections and feeds, and think
this "use a feed idea" over.
Clever :-)
Clearly my argument that there is nearly no information content to
the <service> document struck a cord. Now you want to fill it out
quickly so that the argument seems less relevant. You can now
understand why this argument could not be made early on in the
discussion. Had it been made earlier the group would have wasted huge
amount of time arguing about all kinds of extensions to a document
that is clearly not really needed.
But here is a stronger argument still against the need for a
<service> document. Whatever way you wish to aggregate information
about feeds (and there will be many different ways of doing this, I
can think up a few in a second), there is no need for this. You can
always publish such documents to a feed by POSTing it to a feed url.
This will create a new entry with the information required.
So why not for example use rdf with the AtomOwl vocabulary to put
this information across? Here is an
example doc:
@prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#>
<http://example.org/reilly/main> a :Feed;
:title "My Blog Entries"^text;
:accept "application/atom+xml".
<http://example.org/reilly/pic> a :Feed;
:title "My Blog Entries"^text;
:accept "image/*".
<http://example.org/reilly/list> a :Feed;
:title "Remaindered Links";
:accept "application/atom+xml".
I am not saying that this is the best way of doing things (or even
that this would be
correct AtomOwl btw.) I am just proposing this as an example.
Now you could take the above document and POST it to
<http://example.org/reilly/>
which would create a new entry of information about feeds, no
different from information about any other resource really. It may be
a nice shorthand for finding links, but so could an html page with
links to feeds.
All that is needed is for a feed to contain an <app:accept>...</
app:accept> extension.
And so I don't see why we are in the business of designing such a
document. This is after all the
Atom PROTOCOL!
Cherio,
Henry
cheers
Bill
