Sjoerd Visscher wrote:
> 
> Sam Ruby wrote:
> 
>> Apparently, consuming tools are welcome to aggressively substitute
>> references to the enclosing parent document of any element for any
>> references that, when resolved according to xml:base, differ from that
>> xml:base only in ways that deal with normalization and fragment
>> identifiers.  This can only cause confusion if the xml:base in effect
>> differs from original xml:base of the document (i.e., the URI used to
>> retrieve the document in the first place) in ways other than the
>> fragment identifier.
> 
> You've nailed it.

Cool.  Took me long enough.

>> Note that I'm sidestepping all questions about who is right or wrong. 
> 
> I totally agree, there is no right or wrong here. The established usage
> of a base URI is so different from what Roy is saying that he shouldn't
> have changed the RFC in such a way. (The RFC is even an Internet
> Standard, defined as "a specification that is stable and well-understood.")

I'm sure that we can find established usages where the consuming tool
has various degrees of "agressiveness".  Pure speculation on my part,
but now that I have been able to see how limited in scope this issue is,
I can see where spec authors might have had trouble outlawing one
behavior or another, and decided that publishing a spec within a
reasonable timeframe was of greater value than resolving this issue.

>> The recommendations produced by the feed validator will focus on the
>> areas where the user is most likely to stumble into this problem.  It
>> seems to me that the largest problem area is at the feed level, and the
>> recommendation will be to either make xml:base at the feed level match
>> the URI from which the feed was loaded, or (paradoxically enough) to
>> reference a resource that you are unlikely to directly reference later
>> in the document.  Referencing a parent directory of any given document
>> is OK, what's important is that it isn't the document itself.
> 
> Yes, although I wonder how you would test for "unlikely to directly
> reference later".

I will only test for actual references that meet the criteria described
at the top of this note.  When I encounter such a condition, I will emit
a warning containing a one line message accompanied by a link.  That
link will take the user to a web page that repeats the one line message,
provides an explation of that message (probably close to what I said at
the top of the page), provide a recommendation (probably close to what I
said in the second paragraph above this one), and a link to the
feedvalidator mailing list.

- Sam Ruby

Reply via email to