Walter Underwood wrote:
--On August 30, 2005 11:39:04 AM +1000 Eric Scheid <[EMAIL PROTECTED]> wrote:
Someone wrote up "A Robots Processing Instruction for XML Documents"
http://atrus.org/writings/technical/robots_pi/spec-199912__/
That's a PI though, and I have no idea how well supported they are. I'd
prefer a namespaced XML vocabulary.
That was me. I think it makes perfect sense as a PI. But I think reuse
via namespaces is oversold. For example, we didn't even try to use
Dublin Core tags in Atom.
PI support is required by the XML spec -- "must be passed to the
application."
The challenge here is that there is nothing which requires that PI's be
persisted by the application. In other words, should an aggregator like
pubsub.com preserve PI's in an Atom document when it aggregates entries
on to end consumers? Where should the PI go? If an aggregator pulls in
multple entries from multiple feeds, what should it do if those feeds
have different nofollow, noindex and noarchive PI's? Also, is the PI
reflective of the document in which they appear or the content that is
linked to by the document? e.g. is it the atom:entry that shouldn't be
indexed or the link href that shouldn't be indexed or both... or does
putting the PI on the document level have a different meaning that
putting it on the link level? etc etc
Having x:index="yes|no", x:archive="yes|no", x:follow="yes|no"
attributes on the link and content elements provides a very simple
mechanism that a) fits within the existing defined Atom extensibility
model and b) is unambiguous in it's meaning. It also allows us to
include atom:entry elements within SOAP Envelopes which are not allowed
to carry processing instructions.
-1 to using PI's for this. Let's not introduce a third way of extending
Atom... with appologies to Monty Python: "There are TWO ways of
extending Atom.... link relations and namespaces... and PI's... There
are THREE ways of extending Atom......"
- James
