Well, what I'm going for more is an understanding of what should happen
during parsing. For example, in Section 5 we dictate that "Atom
Processors MUST NOT reject an Atom Document containing ... a signature
because they are not capable of verifying it"... the MOST I think could
be done in the core spec is a similar statement saying "Atom Processors
MUST NOT reject an Atom Document containing a content media type that it
doesn't understand". Whatever else the processor does with it (e.g.
ignore it, display a warning to the user, attempt to find an application
to handle the content, etc) is up to the implementation.
A. Pagaltzis wrote:
* James M Snell <[EMAIL PROTECTED]> [2005-06-17 20:15]:
currently there appears to be no language about what should
happen if an Atom processor encounters a content media type
that it doesn't understand. Should it ignore the content? Does
it report an error? Should it try to process the content
somehow (e.g. defer to some external processor)?
The spec is supposed to explain what the bits means, but not to
tell anyone what to do with them, so there’s nothing it can
really mandate here. Certainly it can’t usefully *enforce*
anything.
This might be something that the implementor’s guide should
contain recommendations for. But even then, I don’t think that
doing more than suggesting a few best practices for a handful
of situations is feasible.
I expect that many newsreaders will simply ignore things they
don’t understand.
Personally, in the aggregator I occasionally work on, I plan to
pass the data to a whatever application the user’s mailcap says
is responsible for it. (I suppose you’d use the registry in
Windows; I don’t know what mechanism OS X provides.)
On the other hand, many scenarios will (hopefully!) involve Atom
feeds intended solely for consumption by machines rather humans.
I imagine that in at least a few of those, unexpected content
types should set off alarms.
So I don’t think there is any one course of action that we can
recommend for everyone; let alone mandate, if such a thing even
was in the scope of the spec. The best we could do is to
informally suggest certain practices for certain situations. (I’d
like to see desktop aggregators widely support what I am planning
to do with mine, f.ex; then putting stuff other than HTML in
feeds would have a chance to catch on.) And that too is probably
something the guide should do, not the spec.
Regards,
