On 17 Aug 2005, at 00:14, Mark Nottingham wrote:
On 16/08/2005, at 3:05 PM, Robert Sayre wrote:
I suggested writing the next tag like this:
<link type="http://purl.org/syndication/history/1.0/next"; href="./
archives/archive1.atom">
That's what I would do, too. Not my spec, though. Mainly so I could
put a title in that said "Entries from August" or whatever.
For that matter, if Henry's interpretation were correct, the
element could be
<fh:history nonsense="1">./archives/archive1.atom</fh:history>
And Atom processors would magically know that XML Base applies to
the URI therein. It's the magic that I object to; inferring the
applicability of context based on the presence or absence of other
markup isn't good practice, and will lead to practical problems.
E.g., what if I want to have an optional attribute on an empty
element? Is it "simple" or "complex"?
Yes. I agree the problem also exists for complex extensions. My
question is the following:
How can a parser that parses atom and unknown extensions, know when
to apply the xml base to
an extension element automatically?
Clearly if the extensions themselves were to use only xlink:link
elements that would be easy.
(though atom itself does not give a good example by not following
that principle). Is there
a place that parsers can get information where they can automatically
tell that an attribute is a
xlink:link copycat? Or how do they tell that the content of an
element is a URI? Can DTDs or RelaxNG files help? If they could
help, would they be retrievable mechanically by a processor of
xml to help it work out how to deal with relative references?
Anyway to summarise: if you don't want to use the atom:link element
then perhaps it would
be best to use the xlink:link attributes. I have only read that spec
quickly [1] but this would
mean that the following
<fh:history xlink:href="./archives.archive1.atom">
would widely be understood to work with the xml:base.
Henry Story
[1] http://www.w3.org/TR/2001/REC-xlink-20010627/
This interpretation of extensions seems very fragile to me.
--
Mark Nottingham http://www.mnot.net/
