, instead of just staying ignorant about it.
--
Sjoerd Visscher
http://w3future.com/weblog/
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
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/
Nikolas 'Atrus' Coukouma wrote:
Sjoerd Visscher wrote:
Why not support hyperlinks too?
So besides:
link rel=alternate type=application/atom+xml title=Main Atom
feed href=/xml/index.atom
also:
a rel=alternate type=application/atom+xml
href=/xml/index.atomMain Atom feed/a
Most webpages already have
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/
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/
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
.
So, link href='' / links to the atom file (as currently in memory),
not your site.
--
Sjoerd Visscher
http://w3future.com/weblog/
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/
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
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/
A. Pagaltzis wrote:
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-18 11:50]:
Yes, your link href= / 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
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
to the original
file.
--
Sjoerd Visscher
http://w3future.com/weblog/
.
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/
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/
purpose of a base URI isn't explained in rfc3986.
--
Sjoerd Visscher
http://w3future.com/weblog/
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
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
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/
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
for unlikely to directly
reference later.
Fair enough?
Totally, thanks!
--
Sjoerd Visscher
http://w3future.com/weblog/
://www.feedvalidator.org/docs/warning/SameDocumentReference.html
--
Sjoerd Visscher
http://w3future.com/weblog/
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
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.:
link href=. xml:base=http://example.com/blog/feed.atom; /
This is also more consistent
-handler.html#adef_handler_type
--
Sjoerd Visscher
http://w3future.com/weblog/
in the
current document.
--
Sjoerd Visscher
http://w3future.com/weblog/
. 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/
28 matches
Mail list logo
