Hi James,
I am afraid I have to side with Graham.
* James Holderness [EMAIL PROTECTED] [2006-01-17 00:30]:
It's crappy assumptions like this that made RSS hellish to
work with. Atom is unambiguous. application/xhtml+xml means
the page content is a full standalone web page.
Not true. Atom
It's crappy assumptions like this that made RSS hellish to work with. Atom is
unambiguous. application/xhtml+xml means the page content is a full
standalone web page.
Not true. Atom *recommends* that the page content is a full standalone web
page. It's not a requirement.
Atom also says that
A. Pagaltzis wrote:
No. RFC4287 does not merely recommend it, it RECOMMENDS it.
I don’t know about you, but I consider a SHOULD to be pretty
strong language.
I consider it as strong as its definition which clearly says: there may
exist valid reasons in particular circumstances to ignore a
On Jan 17, 2006, at 11:04 AM, James Holderness wrote:
but I think I've shown some pretty compelling reasons why a
producer (if they really absolutely have to use application/xhtml
+xml), would be wiser to use an xhtml document fragment than a
complete xhml document.
I'm all for consuming
Hi James,
* James Holderness [EMAIL PROTECTED] [2006-01-17 19:10]:
Aggregators which process @type='application/xhtml+xml' as if
it was @type='xhtml' are in error. Period.
This argument I don't understand. The spec, while recommending
(super strongly recommending, if you will) that the content
A. Pagaltzis wrote:
Aggregators which process @type='application/xhtml+xml' as if it
was @type='xhtml' are in error. Period.
To recommend conflating `xhtml` and `application/xhtml+xml` is to
deprive content producers of precise expressibility of intent.
So what is your intent? What do you
Robert Sayre wrote:
Not true. Atom *recommends* that the page content is a full standalone
web
page. It's not a requirement.
Atom also says that you should expect it not to work.
You shouldn't expect any MIME types to work, or specifically MIME types that
aren't full standalone documents?
Antone Roundy wrote:
I'm all for consuming applications that want to be really smart checking
whether the content of content type=application/xhtml +xml is a
fragment or a complete document and handling either, but if your content
is an xhtml document fragment, is there any reason at all
Tuesday, January 17, 2006, 9:48:22 PM, I wrote:
Eg: perhaps the publisher is attempting to send a HTML document that
they saved in Word, full of CSS styles, that is intended for printing. [*]
[*] Off-topic rant:
Let's hope that the user doesn't attempt to publish their document
as .mhtml,
Tuesday, January 17, 2006, 8:39:54 PM, James Holderness wrote:
This has got nothing to do with second-guessing. Just pretend for a moment
that there was no such thing as the xhtml type. Now the question is what
is the correct way for an aggregator to display an application/xhtml+xml
James Holderness wrote:
Antone Roundy wrote:
I'm all for consuming applications that want to be really smart
checking whether the content of content type=application/xhtml
+xml is a fragment or a complete document and handling either, but
if your content is an xhtml document fragment, is
I wouldn't either, but I wouldn't expect an Atom aggregator to fail to
subscribe to such a feed,
which is what happened to Thunderbird on my test feed [1]
Heh. Twice in one day. That's an unrelated bug.
More to the point, I can't see what you're trying to accomplish here.
You found a way to
Robert Sayre wrote:
Heh. Twice in one day. That's an unrelated bug.
I suspected it was probably unrelated. I tried to reproduce it with a
simpler case and it didn't have any problems subscribing. I just didn't have
time to experiment any more. If you want another problem to investigate, try
David Powell wrote:
Assuming that the document's /html/head section is irrelevant and
discarding it, even when the publisher has specifically used non-core
types to send the full document, is second-guessing the user though.
Fair enough, but you could also say that anyone filtering out
On 18 Jan 2006, at 3:06 am, James Holderness wrote:
The problem it that proving something is quite likely to work
says nothing about whether it would be valid and/or safe, even
in the limited context of XHTML.
True, but sometimes people have to make decisions based on the
limited
James M Snell wrote:
First off I wouldn't recommend using XML content at all because I don't
think the aggregator support is very widespread yet. But if you were
-1, bad recommendation. Applications should feel free to use the full
capabilities of Atom content model regardless of current
Graham Parks wrote:
True, but sometimes people have to make decisions based on the limited
information available to them. Knowing that something is quite likely
to work is better than not knowing anything at all.
No it isn't.
Ok. If you like working in the dark I'm not going to try and
17 matches
Mail list logo
