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.
<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.
<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.
<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?
Is this better or worse than the yahoo/itunes approaches? Why?
Looks better so far. Less reinvention of core elements.
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".
Regards
James
