Re: Does xml:base apply to type="html" content?
Anne van Kesteren wrote: Quoting James Holderness <[EMAIL PROTECTED]>: I think the issue of neutral link bookmarking is unlikely to be a problem for Atom aggregators though. Server bugs are another thing, but I think most feeds will be broken without an explicit xml:base anyway, so maybe that's not worth worrying about. I'm not sure though. Should the WG recommend ignoring Content-Location as a base URI, or should aggregators follow the RFC exactly as specified? If `Content-Location` is not usable or can't be used consistent on a website (for example, using it for both Atom and HTML content) I suggest we specify something that is consistent with what browsers do. And perhaps try to obsolete the relevant header if possible... The problem is not with Content-Location, but with RFC 3986. It says that same-document references must be resolved with respect to the base URI. It adds that when those references are resolved, they should not result in a new retrieval action, but that does not help with things like bookmarking (as James pointed out), and is almost impossible to implement. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Does xml:base apply to type="html" content?
I also understand there is some debate whether supporting Content-Location is a good idea at all (at least in web browsers). Firefox at one point started adding support, but they determined that it caused problems with broken servers (mostly IIS I believe). As far as I, support for Content-Location was reverted because in Firefox same-document references are broken when used with some sort of base URI. I.e. if you have a document with with Content-Location: http://y/z, Firefox will go to the anchor named x in the document at http://y/z, instead of to the anchor named x in the current document. -- Sjoerd Visscher http://w3future.com/weblog/
Re: How to specify multiple alternative encodings of the same content?
J.B. Nicholson-Owens wrote: I maintain NewsFromNeptune.com, a website which points to an archive of recordings of a weekly political talk show called "News from Neptune". I'm considering using ATOM so listeners can be notified about new episodes entering the archive. I'd like to be able to tell the user's software that there are multiple encodings of the same show, one in Ogg Vorbis, another in FLAC, and a third in Speex. Given a URI to each encoding, the client could pick which one is appropriate for downloading. How do I specify this in ATOM? Ideally, just like in XHTML 2.0[1], I think the type attribute should have the option of providing multiple content-types. So the link would become: href="show" /> Or with preferences: Or even with multiple languages: href="show" hreflang="en-CA, fr-CA" /> But this would require HTTP content negotiation, which I think is not practical for most users. [1] http://www.w3.org/TR/xhtml2/mod-handler.html#adef_handler_type -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Sam Ruby wrote: URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform xml:base = http://w3future.com/weblog/rss.xml?notransform Ah, ok, I missed that. (Just to be sure, you added www yourself, or is there a link to the feed somewhere with www in it?) Your feed is available from both of the URI's mentioned above. The tinyurl quoted above is based on passing the first one to the feed validator. Oh, this is actually interesting. I send a 301 when you use www.w3future.com. It looks like this is handled transparently by your http library, giving you the file at w3future.com. In that case it should be possible to request the actual uri that is used to get the file. And then there's also the Content-Location header, which sets the base URI. This is used with content negotiation. F.e. (I haven't actually implemented this) if you would send a request to http://w3future.com/weblog/ with the header Accept: application/atom+xml I could send you the atom file with this header: Content-Location: http://w3future.com/weblog/rss.xml?notransform Afaik this is how the HTTP spec suggest to implement content negotiation. Then the value of Content-Location should be considered to be the uri of the document. Regarding the solution, my first suggestion would be to change the xml:base to reference the atom document, e.g.: http://example.com/blog/feed.atom"; /> ... which would resolve to http://example.com/blog/. Is that what we want here? The original in your example is http://example.com/blog/"; />. Not being quite ready to drop the existing suggestion, I simply added another. http://www.feedvalidator.org/docs/warning/SameDocumentReference.html That's what I meant by saying "first suggestion". -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
A. Pagaltzis wrote: What do you think about what I said? Is @rel='self' being a same-document reference a problem? No. As long as xml:base is the same as the document URI. One thing to note is that when retrieving the document from the location @rel='self' refers to, as the external base URI for atom:feed is the one which @rel='self' also references. So when retrieving the feed from its preferred location, @rel='self' will always implicitly be a same-document reference. Yes, good point! -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
A. Pagaltzis wrote: * Sjoerd Visscher <[EMAIL PROTECTED]> [2005-08-21 13:40]: Regarding the solution, my first suggestion would be to change the xml:base to reference the atom document, e.g.: http://example.com/blog/feed.atom"; /> This is also more consistent with the explanation. Except it’s a @rel='self' link, so you really do want it to resolve to <http://example.com/blog/feed.atom>. This was about the link in the solution in http://www.feedvalidator.org/docs/warning/SameDocumentReference.html which is not a self link. In fact, I’ve been wondering whether atom:feed/@xml:base doesn’t obsolete the purpose of atom:[EMAIL PROTECTED]'self'], so that the former should have been the SHOULD that the latter is, and the latter not invented at all. It would seem that this notion would also be less controversial when backported to RSS2, as opposed to the item of including an atom:link in an RSS2 feed. Not only does is port well to RSS2, it ports well to every single xml document. I think it is good practice, as it makes the infoset of the document context independent. -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Sam Ruby wrote: Sjoerd Visscher wrote: Sam Ruby wrote: Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 The explanation in the documentation[1] is perfect. And it says "As the current xml:base in effect does not match the URI of the document", but this is not the case in my feed, so I'm not sure why you report a warning? URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform xml:base = http://w3future.com/weblog/rss.xml?notransform Ah, ok, I missed that. (Just to be sure, you added www yourself, or is there a link to the feed somewhere with www in it?) Regarding the solution, my first suggestion would be to change the xml:base to reference the atom document, e.g.: http://example.com/blog/feed.atom"; /> ... which would resolve to http://example.com/blog/. Is that what we want here? The original in your example is http://example.com/blog/"; />. -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Sam Ruby wrote: Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 The explanation in the documentation[1] is perfect. And it says "As the current xml:base in effect does not match the URI of the document", but this is not the case in my feed, so I'm not sure why you report a warning? Regarding the solution, my first suggestion would be to change the xml:base to reference the atom document, e.g.: http://example.com/blog/feed.atom"; /> This is also more consistent with the explanation. greetings, Sjoerd [1] http://www.feedvalidator.org/docs/warning/SameDocumentReference.html -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
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. 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.") 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". Fair enough? Totally, thanks! -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Bjoern Hoehrmann wrote: * Sjoerd Visscher wrote: It would be really cool if you would move the xml:base of the entry to the div, but as you have 2 divs per entry I can imagine you don't want to do that. Or you could change the base URI to f.e. When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't dereference to anything) xml:base is not allowed on xhtml1:div elements. Doh. The imperfections of the real world make it sometimes overwhelmingly disappointing. -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Tim Bray wrote: On Aug 15, 2005, at 7:28 AM, Tim Bray wrote: The way Tim Bray's feed and the examples from James Snell on developerWorks use xml:base is what Roy T. Fielding calls an abuse. I disagree with Roy, Shouldn't he be the one who knows? He actually he made it into an abuse by changing the definition of same-document references in the new rfc, so some documents that used the base URI in a way it was (apparently) never intended break. Read his whole argument if you want: http://lists.w3.org/Archives/Public/uri/2004Jan/0009 It would be nice to know how bad he actually thinks the abuse is. > but agree that the way my links were set up was a little surprising to the eye, so I tweaked. Check out http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.tbray.org% 2Fongoing%2Fongoing.atom It would be really cool if you would move the xml:base of the entry to the div, but as you have 2 divs per entry I can imagine you don't want to do that. Or you could change the base URI to f.e. When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't dereference to anything) -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Robert Sayre wrote: On 8/15/05, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * Robert Sayre <[EMAIL PROTECTED]> [2005-08-15 19:05]: The implementors of Internet Explorer and Mozilla agree with Sam. http://www.franklinmint.fm/2005/08/15/base.html That uses html:base, which sets the base URI for the entire document, not @xml:base, which sets the base URI for the element and its children. Your example is irrelevant. Oh no, not irrelevance! :) Both seem to do the job described in section 5.1.1 of RFC 3986, "Base URI embedded in content". <http://rfc.net/rfc3986.html#s5.1.> Just for fun, I made a version that uses xml:base instead. You can try it with Firefox, which happens to support xml:base: <http://www.franklinmint.fm/2005/08/15/base.xhtml> Yes, it's a known bug. https://bugzilla.mozilla.org/show_bug.cgi?id=275689 As a result of that bug, same-document references in documents with xml:base or html:base (like documents from the Google cache) don't work. Also content-location support is removed in Firefox because it broke same-document references (which hadn't be the case if same-document references would have been correctly implemented in the first place.) -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Sam Ruby wrote: Sjoerd Visscher wrote: Not quite, it is a nitpick, but I think the source of our disagreement. Resolution is the procedure of making absolute paths from relative paths. So the link resolves to <http://www.tbray.org/ongoing/>. But this is equal (string-equal) to the base URI, so this is a same-document reference. In the sentence above, you refer to "the base URI". I would interpret that as "the base URI of the document", not "the base URI of the element". It has to the base URI of the element, otherwise links can change meaning when you XInclude them in another document. The problematic values are the ones that when resolved are the same as the base URI (ignoring the fragment). In this case even http://www.tbray.org/ongoing/"/> would be problematic. My reading of this statement is that your feed also contains a problematic link. Issuing warnings on what is unambiguously a fully qualified URI and on your usage are things I would rather avoid. Why? -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Sam Ruby wrote: Sjoerd Visscher wrote: Let me show you some pseudo-code that implements how to dereference an atom link according to rfc3986: dereference(linkElement) = baseURI = linkElement.baseURI linkURI = makeAbsolute(linkElement.href, baseURI) if stripFragmentID(linkURI) == stripFragmentID(baseURI) then return linkElement.ownerDocument else return loadDocument(linkURI) You'll see the problem when you pass the link element of Tim Brays feed. Focusing on the in Tim's existing feed, it seems to me that Tim intended to express <http://www.tbray.org/ongoing/>. How you interpret the spec is that this will actually resolve to <http://www.tbray.org/ongoing/ongoing.atom>. Am I correct so far? Not quite, it is a nitpick, but I think the source of our disagreement. Resolution is the procedure of making absolute paths from relative paths. So the link resolves to <http://www.tbray.org/ongoing/>. But this is equal (string-equal) to the base URI, so this is a same-document reference. If so, what would happen if he replaced this with ? linkURI would still resolve to the same value as baseURI. Do you interpret the spec is that this will also resolve to <http://www.tbray.org/ongoing/ongoing.atom> / resolves to <http://www.tbray.org/>, not the same value as the base URI, and not a same-document reference. How about ? I guess that would depend on what the meaning of "==" is. "==" is string equality in my pseudo-code. I think <./> resolves to <http://www.tbray.org/ongoing/>, so that would be a same-document reference as well. I am quite willing to add feed validator warnings for edge cases where reasonable professionals might have differing opinions of how to read the specification, particularly if there is no compelling use case for use of the feature. Can we agree that empty //atom:link/@href values, or //atom:link/@href values that consist entirely of a fragment are problematic? The problematic values are the ones that when resolved are the same as the base URI (ignoring the fragment). In this case even href="http://www.tbray.org/ongoing/"/> would be problematic. -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Bjoern Hoehrmann wrote: * Sjoerd Visscher wrote: Now I think that no matter what we decide, we should not do something that the writer of the URI spec thinks is an abuse. "We" as in there is specific text in one of the atompub drafts that make misleading suggestions that are inconsistent with the xml:base Recommendation or RFC 3986/7 other than some con- fusion about how to handle IRIs in non-Unicode encoded Atom documents that are not in NFC? I have no problem with the spec, only with some high profile Atom feed examples. -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base abuse
Sam Ruby wrote: I would prefer to deal with what the spec actually says. As you point out, it is "really odd" that nothing was added to the new RFC 3986 to support your position. The authors of DOM3 looked at both the xml:base and InfoSet specifications. I've taken a look at how two respected XML parsers have implemented DOM3: http://www.intertwingly.net/blog/2005/08/12/xml-base-support - Sam Ruby Yes, that code is perfectly fine, and not the actual problem. Let me show you some pseudo-code that implements how to dereference an atom link according to rfc3986: dereference(linkElement) = baseURI = linkElement.baseURI linkURI = makeAbsolute(linkElement.href, baseURI) if stripFragmentID(linkURI) == stripFragmentID(baseURI) then return linkElement.ownerDocument else return loadDocument(linkURI) You'll see the problem when you pass the link element of Tim Brays feed. Also, Roy T. Fielding says "[...] a person is deliberately abusing the base URI by assigning it an unrelated URI for the purpose of creating an artificial shorthand notation for external references." There is nothing in rfc3986 that contradicts this, it only indirectly hints to it. The real purpose of a base URI isn't explained in rfc3986. -- Sjoerd Visscher http://w3future.com/weblog/
xml:base abuse
Hi, A while ago we had a discussion about how xml:base should be used. We didn't reach a conclusion, but I think we need to act. The way Tim Bray's feed and the examples from James Snell on developerWorks use xml:base is what Roy T. Fielding calls an abuse. Now I think that no matter what we decide, we should not do something that the writer of the URI spec thinks is an abuse. More here: http://w3future.com/weblog/2005/08/#howToUseBaseUris -- Sjoerd Visscher http://w3future.com/weblog/
Re: Notes on the latest draft - xml:base
James Cerra wrote: xml:base is a broken specification. At the simplest, it's just a lame attempt at abbreviating strings. However, it solves that problem in the worst possible manner. As the RDF serializations show, what is needed is a name/value pair simular to entities or xml namespaces. That's because it is not an attempt at abbreviating strings, but to preserve the meaning of relative URIs, when content is used outside of its original context. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
A. Pagaltzis wrote: But the language in RFC3986 does not consider this use case, and the language in the xml:base TR does not address same-document references at all. So there are things possible in the scope of the xml:base TR, for whose behaviour it defers to the RFC, which only considers a small subset of the possible use cases. So we have a mismatched layering of specs, for a certain class of use cases… ugh. I think Roy T. Fielding did consider all this, given the example in http://lists.w3.org/Archives/Public/uri/2004Jan/0012 Also interesting is this quote from http://lists.w3.org/Archives/Public/uri/2004Jan/0009 "That is, the correct behavior is to parse the reference into a URI before deciding whether or not it is a same-document reference. The effect of this change, when implemented, has no impact on the protocol *except* when a person is deliberately abusing the base URI by assigning it an unrelated URI for the purpose of creating an artificial shorthand notation for external references. It should be no surprise that such usage will not be supported by the standard, since it never worked with the majority of deployed implementations." -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
A. Pagaltzis wrote: It makes me wonder whether the person who wrote the example was unaware of the consequences of the same-document reference specifications in the URI RFC. Surely, the xml:base WG must have noticed this issue and discussed it? I wonder how many people are aware of it. I wonder if we managed to convince any readers on the atom list at all. Tim Bray hasn't responded yet, so I guess he is still in doubt. I found out about it through Mozilla Bug 241981. https://bugzilla.mozilla.org/show_bug.cgi?id=241981 Mozilla had implemented that the http content-location header sets the base href. But as Mozilla has no same-document reference support, it would navigate to the content-location document when you clicked on an internal link. The solution was to revert content-location support, and noting that it was broken-by-design. I found this hard to believe, and tried figuring out what was really supposed to happen. Notice that xml:base describes **a base URI**. The xml:base TR does not define what a base URI is. It’s RFC3986 (and originally, RFC2396) which does, while describing just what an URI is, to begin with. The same-document reference stanza in the URI RFCs is clear evidence that in the spirit of the spec, “base URI” means “the source URI of the content,” not “the prefix I wish to apply to relative references.” RFC2396 is not the original spec, HTML 2 is. Later versions of HTML screwed up. I wrote up the history of fragment identifiers here: http://w3future.com/weblog/2005/01/ At first, I thought the RFC-specified same-document reference stanza made no sense. But then I realized it is perfectly fine and absolutely desirable for the case where the “base URI embedded in content” applies to the entire document. It is the xml:base TR which is at odds with this; applying same-document reference behaviour to fragments of an aggregate document is non-sensical. The more I think about it, the more it seems like this interaction is Broken As Designed. xml:base should not have adopted the “base URI” term – basically, it appears that the very attribute name itself is a misnomer. I don't find applying same-document reference behaviour to fragments of an aggregate document non-sensical. If I XInclude a piece of XHTML that has same-document references in it, I still want them to be same-document references, and they should not link back to the original file. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
A. Pagaltzis wrote: * Sjoerd Visscher <[EMAIL PROTECTED]> [2005-07-19 01:25]: A. Pagaltzis wrote: He is correct, Tim. The base URI means “the URL where this document was found,” not “the prefix for any enclosed relative links.” I don’t see how RFC3986 can be read any other way. I am correct ;), but your explanation is wrong. 5.1 says clearly that the "Base URI embedded in content" precedes any other way of establishing a base URI. You misunderstood what I said. The point is that regardless of how the base URI is determined (whether it is embedded in content or otherwise), it *means* that the content it applies to was actually found at the base URI. It’s not simply any arbitrary old prefix defined for convenience. Ah, yes, you are absolutely right. I missed that you said "means" instead of "is". That is my interpretation too, but only through the way the base URI is used. I can't find any hint in that direction otherwise. It would be nice if T. Berners-Lee, R. Fielding or L. Masinter could confirm that. If it would have been worded specifically that way, then xml:base could have been seen as the self link for all xml documents. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
A. Pagaltzis wrote:
* Sjoerd Visscher <[EMAIL PROTECTED]> [2005-07-18 11:50]:
Yes, your resolves to
http://www.tbray.org/ongoing/ But if you say "follow that link"
in a program with same-document references support, it will
say: "Ok, the link points to http://www.tbray.org/ongoing/, and
the base URI is http://www.tbray.org/ongoing/ as well, so I
have to return the current document instead of doing a new
request."
He is correct, Tim. The base URI means “the URL where this
document was found,” not “the prefix for any enclosed relative
links.” I don’t see how RFC3986 can be read any other way.
I am correct ;), but your explanation is wrong. 5.1 says clearly that
the "Base URI embedded in content" precedes any other way of
establishing a base URI. So the base URI is
<http://www.tbray.org/ongoing/>, and the empty relative URI therefore
refers to <http://www.tbray.org/ongoing/>.
But now the "URI reference refers to a URI that is, aside from its
fragment component (if any), identical to the base URI", so it is a
same-document link, and when "a same-document reference is dereferenced
for a retrieval action, the target of that reference is defined to be
within the same entity (representation, document, or message) as the
reference; therefore, a dereference should not result in a new retrieval
action."
It is a very complicated way of calculating that an empty relative URI
is always the current document, no matter what the base URI is.
So it would be
ongoing
...
If you want it to be perfect xml:base on the entry would be the URI of
the Atom Entry Document. And the html base URI should go on the xhtml
div element. Just like you get when the entries and the div elements are
XIncluded.
If we wanted to avoid this, we should have added language to the
spec that atom:[EMAIL PROTECTED]'alternate'] should never be considered
a same-document reference, maybe.
If your XML package has support for data-typing, xml:base and
same-document references, then you could no longer do
Node n = link.getAttribute("href").dereference();
because Atom would no longer follow standard behaviour.
--
Sjoerd Visscher
http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Tim Bray wrote: On Jul 17, 2005, at 8:16 AM, Sam Ruby wrote: Upon further reading of 3986, I'm convinced that Tim's current feed is correct. I think so too, but I'm worried how XML-reader implementations will do supporting all this base-URI stacking. If this kind of thing is going to cause breakage, maybe it's not good practice. Consider this in the context of http://diveintomark.org/archives/2004/08/16/specs However, Base URI Embedded in Content. In XML documents, this takes the form of xml:base attribute values. This is the case in Tim's feed. And further note that our section 2. of the Atom spec specifically calls out 5.1.1 of 3986; so I think the rules are on my side. -Tim Section 5.1.1 has nothing to do with the problem. Yes, your resolves to http://www.tbray.org/ongoing/ But if you say "follow that link" in a program with same-document references support, it will say: "Ok, the link points to http://www.tbray.org/ongoing/, and the base URI is http://www.tbray.org/ongoing/ as well, so I have to return the current document instead of doing a new request." The changes of that happening are quite slim, I know, but your feed will be used as an example, and should avoid anything that could lead to problems, however slim the chances. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Graham wrote: On 17 Jul 2005, at 7:18 pm, Bjoern Hoehrmann wrote: Read e.g. <http://lists.w3.org/Archives/Public/uri/2004Jan/0012>. So the assertion is that if a link happens to be the same as xml:base, then the current document should be considered to *be* the document at xml:base? That's ludicrous and arbitrary. No. It requires the correct point of view of what a base URI actually means. It's not just a handy tool to shorten URI references. It is meant to indicate the original URI of the content, for when the context is used somewhere else. It has always been that way, see f.e. a quote from a really old HTML spec (1992): Base Address Anchors specify addresses of other documents, in a from relative to the address of the current document. Normally, the address of a document is known to the browser because it was used to access the document. However, is a document is mailed, or is somehow visible with more than one address (for example, via its filename and also via its library name server catalogue number), then the browser needs to know the base address in order to correctly deduce external document addresses. http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html#11 Nowadays good examples are Google cache, the wayback machine and XInclude. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Graham wrote: On 17 Jul 2005, at 4:20 pm, Sjoerd Visscher wrote: Where did you read that same-document references only apply when there is no embedded base URI? Scroll down to the algorithm in 5.2.2, and it backs up Tim and Sam, in particular this: if (R.path == "") then T.path = Base.path; Yes, so if the URI reference is empty, then the target path is the base path, and so with embedded base URIs it is the embedded base URI. To again quote the spec: "When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5.1), that reference is called a "same-document" reference." This is all done after the algorithm has run, which specifically says that the uri is identical to the base URI, so it is a same-document reference. It seems pretty clear to me that whoever wrote the same-document references section simply wasn't thinking about embedded base URIs, and thus it can be safely ignored. Your interpretation would contradict not just the algorithm but practically the whole of the rest of the document. Not at all. You have to remember that beging a same-document reference sais nothing about what the URI actually is, but only that: When a same-document reference is dereferenced for a retrieval action, the target of that reference is defined to be within the same entity (representation, document, or message) as the reference; therefore, a dereference should not result in a new retrieval action. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Bjoern Hoehrmann wrote: * Sjoerd Visscher wrote: And that's why you can't use it as a reference to your site. That depends a bit on same-document reference processing of Atom processors. If the Atom processor assumes the link refers to some web site and passes the absolute reference to some other user agent there would not be a problem. If however e.g. FireFox implements some Atom rendering and makes the link available to the user, it might indeed consider the link to point to the same document and not navigate to the web site. If that's a concern, Tim cannot use http://www.tbray.org/ongoing/ as Base URI. That would of course make using xml:base a bit difficult in practise... Actually, it makes using xml:base possible, when there are same-document references involved. There is a bug in Firefox [1] about this. This means that same-document links don't work in f.e. Google cache files. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=275689 -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Sam Ruby wrote: Upon further reading of 3986, I'm convinced that Tim's current feed is correct. Base URI defaults to the Retrieval URI. This gives rise to the common use case of "same-document" references. However, Base URI Embedded in Content. In XML documents, this takes the form of xml:base attribute values. This is the case in Tim's feed. Where did you read that same-document references only apply when there is no embedded base URI? -- Sjoerd Visscher http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Sjoerd Visscher wrote:
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that "path-empty" was a valid URI-reference.
Yeah, it means "here".
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers to a URI that is, aside from its fragment
component (if any), identical to the base URI (Section 5.1), that
reference is called a "same-document" reference. The most frequent
examples of same-document references are relative references that are
empty or include only the number sign ("#") separator followed by a
fragment identifier.
When a same-document reference is dereferenced for a retrieval
action, the target of that reference is defined to be within the same
entity (representation, document, or message) as the reference;
therefore, a dereference should not result in a new retrieval action.
So, links to the atom file (as currently in memory),
not your site.
Actually, after thinking about it some more, even
would *not* really be a
link to your site, because it is still identical to the base URI.
So you can't use http://www.tbray.org/ongoing/ as your base URI.
And actually it makes much more sense to user the uri of your atom file
as base URI. (IMHO it is good practice to always set the URI of the file
as xml:base on the root element.)
So I'd suggest:
ongoing
--
Sjoerd Visscher
http://w3future.com/weblog/
Re: Atom 1.0 xml:base/URI funnies
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that "path-empty" was a valid URI-reference.
Yeah, it means "here".
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers to a URI that is, aside from its fragment
component (if any), identical to the base URI (Section 5.1), that
reference is called a "same-document" reference. The most frequent
examples of same-document references are relative references that are
empty or include only the number sign ("#") separator followed by a
fragment identifier.
When a same-document reference is dereferenced for a retrieval
action, the target of that reference is defined to be within the same
entity (representation, document, or message) as the reference;
therefore, a dereference should not result in a new retrieval action.
So, links to the atom file (as currently in memory),
not your site.
--
Sjoerd Visscher
http://w3future.com/weblog/
Re: The Atomic age
Dan Brickley wrote: Let me emphasise that I'm not claiming these Atom docs "are" reasonably interpreted as RDF. Just that they seem to, by happy coincidence as it were, at least share a syntax with RDF. The intepretation of this syntactic state of affairs is up for discussion. I've never understood what makes hybrid RDF/other xml formats appealing. A simple xslt conversion turnes the xml format (the whole format, not a subset) in much better RDF, with no compromises. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Autodiscovery
Nikolas 'Atrus' Coukouma wrote: Using @rel with any linking element is perfectly valid and has been for years. @rel not being supported for anything other than the link element itself has also been an outstanding bug for just as long. There's lot of debate attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20). Can we agree that this should be supported, but currently isn't? Unless there's a compelling reason not to, I think we might as well allow autodiscovery via either element. Any implementation guide should recommend duplicating the information in the interest of autodiscovery actually working. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399 Yes, absolutely, that was my point. As David Baron says in Bugzilla: "The spec was designed with the idea that any application that looked at rel/rev on LINK elements should do the same for A elements." -- Sjoerd Visscher http://w3future.com/weblog/
Re: Autodiscovery
fantasai wrote: The difference between and is that - applies to the document as a whole: it indicates a relationship between this document and the href destination. - is a contextual link: it indicates a relationship between the linking context and the href destination. They have different purposes. It is imho perfectly reasonable to limit autodiscovery to s only. It is also perfectly reasonable to link to feeds with , and expect that the UA will recognize it as a feed rather than a generic XML document. Like I wrote before, this is not how HTML 4.01 (or XHTML 2.0 for that matter) defines the rel attribute on a hyperlink: This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Autodiscovery
Supporting general hyperlinks starts making more sense if we have cases other than alternate (I've written elsewhere about this) because the amount of duplicated information is much greater. If you're only supporting feeds that serve as an alternate form of the content, then it makes sense to repeat one link once just to make the programmer stuck writing the user agent. I'd hope that whatever library/toolkit they're using supports XPath queries. Using them makes it easy to pluck out anything with type="application/atom+xml" and an href property. Maybe atom needs only one link with a rel attribute, but there are others. I have a lot of hyperlinks with rel attributes on my weblog homepage, and I refuse to repeat them all as link elements. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Autodiscovery
Nikolas 'Atrus' Coukouma wrote: Sjoerd Visscher wrote: Why not support hyperlinks too? So besides: also: Main Atom feed Most webpages already have a hyperlink to the feed, so they'd only need to add two attributes. It would be a waste to have to duplicate the information in the document head. The intent of the head element is to indicate a feed that serves as a substitute for the page you're currently viewing. This other case is locating all feeds linked to from a page. For that, the type attribute should be sufficient to indicate that you're linking to a feed. No, a hyperlink with a rel attribute means the same as a link element. The HTML spec describes the rel attribute on the a element thus: This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. -- Sjoerd Visscher http://w3future.com/weblog/
Re: Autodiscovery
Why not support hyperlinks too? So besides: also: Main Atom feed Most webpages already have a hyperlink to the feed, so they'd only need to add two attributes. It would be a waste to have to duplicate the information in the document head. -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base and html rendering
Thomas Broyer wrote: Sjoerd Visscher wrote: The only thing that changes with xml:base support in Atom is that aggregators who *do* resolve relative URIs, now have more chance to get the originally intended base URI. *All* aggregators MUST resolve any relative URI reference. All aggregators must resolve relative URI references in RSS too to work properly. So with Atom the aggregators are broken according to spec, with RSS the aggregators are broken according to practice. Who cares about that difference? -- Sjoerd Visscher http://w3future.com/weblog/
Re: xml:base and html rendering
Roger B. wrote: Requiring URIs in the content to be absolute to begin with is too expensive, and probably completely unenforceable. Graham: I suppose that, if nothing else, it's a self-correcting problem. When all those hybrid RSS/Atom parsers out there display broken images or links, most publishers will get a clue and make sure they're putting absolute URIs in their feeds. And if they don't mind broken images and links, well, I guess it wasn't much of a problem in the first place. You are right. RSS has this problem already, and it isn't really that much of a problem, just a slight annoyance. As aggregators I've only ever used Radio Userland and Bloglines, and they both don't resolve relative URIs correctly. But there still are plenty of RSS feeds with relative URIs in them. The workaround as user is to simply follow the link to the item first, and then click the link there on the original page. The only thing that changes with xml:base support in Atom is that aggregators who *do* resolve relative URIs, now have more chance to get the originally intended base URI. And a side effect is apparently that aggregator writers are alerted to the relative URI problem, instead of just staying ignorant about it. -- Sjoerd Visscher http://w3future.com/weblog/
Re: PaceFeedLink
Eric Scheid wrote: On 26/1/05 2:16 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote: I like the proposal in general though I wonder why an absolute URI is required. One of the intended uses is for when a browser downloads a feed resource to disk, and then hands that file to an atom handler application. Once that happens, the original location context is lost. The whole point of xml:base is that an application that stores a page outside of its original context can add an xml:base to prevent losing the original location context. -- Sjoerd Visscher http://w3future.com/weblog/
