Richard Salz wrote:
Without a schema link at the feed level, how can a client know what the
server is expecting to see?
That's a different case. A schema link within the atom:entry is used to
identify the schema of the top-level element within atom:content. 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.
Just as atom entries in a feed can be a mix of text, html, xhtml, why
can't they be a mix of schema-defined entries? The syntax of text, html,
xhtml are defined out-of-band in the Atom RFC's. I'd like to make it
possible to define them in-band in a feed dcoument.
This is fine but if you go down this route, there are many issues that
need to be dealt with. If you allow schema links at the atom:feed, does
that mean the content of all entries in the feed has to conform to that
schema? What if the entry has a schema link that conflicts with a feed
level schema link? What if there are multiple schema links that specify
the same value for the for attribute? If you take an entry from an
atom:feed containing a schema link and put it into another feed, should
the schema link be added to the entry or should an atom:source element
be added containing the schema link? I think you need to very clearly
define how this is all going to work.
- James
/r$
--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
