Richard Salz wrote:
Schema
links within the atom:feed can be used to identify the schema(s) of the
types of top-level elements that should appear within the feed. Those
are two separate cases, neither of which requires the invention of the
for attribute.
Yes, since atom:content can only have a single child element, then the
@for is superfluous. But I don't understand how to meet the feed issue
without the @for -- can you show me how? Let's say I have a feed that
accepts tns:esb entries and snl:foobar entries.
A schema-link-aware client is likely going to be able to look at the
schema itself to determine what kind of element is defines without the
use of the for attribute.
This is fine but if you go down this route, there are many issues that
need to be dealt with.
It's not clear to me that every single semantic needs to be completely
nailed down (viz,
http://www.dehora.net/journal/2009/02/03/just-use-post/). Looking at RFC
5005, what if a feed contains multiple conflicting archive links? I'll
meet the requirements, I just don't want to be a special case :)
Of course there's no need to define everything but there are simple
steps you can take o reduce the number of things that need to be explained.
- James
/r$
--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
