Robert Sayre wrote: > On 8/15/05, Sjoerd Visscher <[EMAIL PROTECTED]> wrote: > >>Yes, it's a known bug. >>https://bugzilla.mozilla.org/show_bug.cgi?id=275689 > > Well, it's not clear from that bug that any Mozilla committers feel > it's wise to "fix." Even so, they seem to be leaning towards patching > html:a as a special case, in the event that they do anything. > > I'll agree that this should be a warning, and perhaps write something > that willcome back to haunt me--Atom makes a point of leaning many > established specifications. It's unwise to lean on those specs in the > corner cases where they diverge from existing implementations, and a > warning in the feedvalidator is justified in such cases.
What I see occurring here is implementations dealing with the attendent confusions that their users face as the result of an unclear specification of a corner case in a spec. After all this discussion, I am *still* unclear as to where this corner case is. Let me try again. 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. Sjoerd: is this your understanding? Note that I'm sidestepping all questions about who is right or wrong. Different implementations may chose different strategies on how aggressive they wish to be. If my understanding is correct, then I will agree that it is unwise for feeds to express URIs that some consumers will interpret in one way, and others will interpret in an other way; therefore a warning is warranted. If my understanding is correct, I can produce test cases (and would welcome any contributions in this area), and fix the feed validator. 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. And to include an example that matches what Sjoerd's feed (and now Tim's feed) now do. Fair enough? - Sam Ruby
