This proposal seems to cover two very distinct use cases:
1. Provide a way to discover the schema used for the foreign markup
used in an entry served by a feed server
2. Issue a contract to be used by the client to submit new entries to
the server
For 1, this proposal seems to create an alternative to XML Schema
instance mechanisms [1]. Any foreign markup in an entry, including
that which is present inside the atpm:content is free to add the xsi
markup to help the processor identify the schema by which that element
should be processed. Of course, this mechanism works only for W3C XML
schema-based documents. The present proposal is weakened by the
presence of such an existing mechanism for the first use case. To
illustrate this, take the following example:
<feed>
<foreign:meta
xmlns:foreign="urn:foo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:foo http://example.org/schema";>
...
</foreign:meta>
...
<entry>
<foreign:markup
xmlns:foreign="urn:foo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:foo http://example.org/schema";>
...
</foreign:markup>
<content type="application/xml">
<foreign:markdown
xmlns:foreign="urn:foo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:foo http://example.org/schema";>
...
</foreign:markdown>
</content>
</entry>
</feed>
For the second use case, it is best to provide this information in the
context of a collection's metadata alongside existing constraints on
what a server may (or not) accept. app:collection serves the purpose
of just such a container and can be used inside a feed. One of the
necessary things here might be the target for usage of elements from
some foreign (non XHTML and Atom) namespaces. For example, a feed may
advertise what data can be added to it thusly:
<feed>
<app:collection>
<contract:accept>
<contract:element
parent="atom:entry"
schema="..."
type="..."
namespace="...">named_element</contract:element>
<contract:element
parent="atom:content"
schema="..."
type="..."
namespace="...">named_element</contract:element>
...
</contract:accept>
<app:accept>application/atom+xml</app:accept>
...
</app:collection>
...
<entry>
<foreign:markup
xmlns:foreign="urn:foo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:foo http://example.org/schema";>
...
</foreign:markup>
<content type="application/xml">
<foreign:markdown
xmlns:foreign="urn:foo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:foo http://example.org/schema";>
...
</foreign:markdown>
</content>
</entry>
</feed>
Nikunj
[1] http://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation
On Feb 3, 2009, at 8:11 AM, James M Snell wrote:
Rich,
I'm not yet convinced that the for attribute is necessary.
Presumably, the schema format itself will be capable of identifying
which elements it defines, meaning that a schema-aware processor
could identify which schema to apply with relative ease. Further,
since the atom:content element is only going to have a single top-
level element, it would follow that within a single atom:entry
element, there'd only ever be reason for a single schema link in the
entry. schema links at the feed level don't make a lot of sense to
me since the schema link itself is part of the entry metadata.
Lastly, schema links at the feed level imply some kind of
inheritance model for atom:link elements (e.g. an entry would
inherit the schema links of the parent feed). The challenge with
this is that Atom does not define any such inheritance model for
atom:link and experience has shown that inheritance is not
necessarily a good thing.
My suggestions would be to drop the for attribute, limit the schema
link to one instance per entry, and do not use schema links at the
atom:feed level at all.
- James
Richard Salz wrote:
<link rel="schema" href="..." for="foo" />
<link rel="schema" href="..." for="bar" />
<atom:content type="application/xml+something">
<foo:blarg>...</foo:blarg>
<bar:blarg>...</bar:blarg>
</atom:content>
This is close, the link/@for values would actually be
"for='foo:blarg'" for example.
I went back to the RFC and re-read 4.1.3.1. It appears that you
are right, multiple top-level elements inside atom:content are not
allowed. Rats. But we still need link/@for for use at the feed
level, where individual atom:entry/atom:content elements might have
different types of content. Does that make more sense?
(Original, the schema link was intended for content in an atom:feed
document, but other discussion convinced our group that "content"
belonged in atom:content. When I made that change I didn't go back
and carefully check this. Sorry.)
/r$
--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
