On Feb 3, 2009, at 2:21 PM, Richard Salz wrote:
That's an insightful way of looking at it.
I don't think the usecase is weakened by the existance of XSD's
schemaLocation attribute. At least not within the Atom/AtomPub
community,
which seems to like RelaxNG as its schema language.
No matter what language you are using to describe schemas, an approach
that marks the location of a schema document used for an XML namespace
appears superior, IMHO. This allows flexibility of adding markup at
any level inside an entry document and not just in the atom:content
block, which happens to be another real-world use of Atom syntax.
Putting schema links in the collection document make sense. But
having
them in the feed document provides a contract to those doing GET, as
well
as those doing POST.
There is a very well established precedent that any contracts related
to POST should appear in the app:collection. The category and accept
blocks are testimony to this. Moreover, one can treat the proposal
primarily as a way to qualify
<app:accept>application/xml</app:accept>
and that can be done as one of the two mechanisms below inside the
app:collection element:
<app:accept schema:namespace="..." schema:element="...">application/
xml</app:accept>
<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>
/r$
--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
