James Holderness wrote:
James M Snell wrote:
Ok, not a good situation. Like I said before, all it really takes to
get something started here is enough interest from a community of
folks willing to do the work and implement support.
For the record, I'm not interested in supporting anything like this at
the moment. My only interest is in making sure that whatever you do
doesn't render the feed useless to people that don't support the extension.
I'm not convinced that there are very many implementers at all who are
going to be interested.
<category scheme="http://example.org/restriction/country/allow";
term="au us" />
<category scheme="http://example.org/restriction/country/deny";
term="ca fr" />
I'm not sure these are a good fit for the category element. All the
other examples make sense as category elements without the client
knowing anything about the scheme.
+1. it felt odd when I typed it also; but this is a strawman and needs
to be kicked around a bit. Are these really going to be necessary, anyway?
<x:person scheme="http://example.org/roles"; term="director">
<name>Linda</name>
</x:person>
Any reason why these can't be atom:contributor elements, possibly with
an x:role attribute or sub-element? Would be more useful to clients not
supporting the extension and I don't think it would be an inappropriate
use of atom:contributor.
Right. I was thinking the same thing.
<content src="#mpeg type="video/quicktime" />
That doesn't look legal to me. Surely the IRI reference in the src
attribute must be dereferenceable? Section 4.1.3.2 of RFC4287: "Atom
Processors MAY use the IRI to retrieve the content". How does one
retrieve content from a fragment reference?
It is dereferencable... just not in the way most implementations would
likely expect. :-) Anyway, the main point is that given a set of links
with a given rel (e.g. "enclosure") how do we identify which is the
"primary" or "default" representation?
Is this better or worse than the yahoo/itunes approaches? Why?
Looks better so far. Less reinvention of core elements.
Yeah, that was the main goal.
What are the other possible approaches?
As a client developer, I'd want to ask what metadata might be useful to
clients first and foremost. Come up with some use cases that amount to
more than just "have metadata - must publish".
Heh... ok. As a client developer, what metadata might be useful to you? :-)
- James
Regards
James
