Hi James,
* James Holderness [EMAIL PROTECTED] [2006-01-17 21:50]:
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
A. Pagaltzis wrote:
So what is your intent? What do you expect aggregators to do
with that content?
Really, what I expect them to do with that content is to not fail
to display a full document if a full document is what I provide.
That aggregators attempt to render such full documents inline
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
On 16/1/06 5:29 PM, Graham Parks [EMAIL PROTECTED] wrote:
Except no one bothered to tell the aggregator writers they'd have to
implement this, so no it's not safe.
so atom is good for schlepping documents about, but not for elements of
documents (with two exceptions) :-(
e.
Eric Scheid wrote:
then you're not going to like what I was thinking of doing ... posting
atom:category / chunks to an APP/media collection, such that the media
collection entry might look like this (no typos this time, I hope)...
entry
...
content type=application/atom+xml
On Jan 15, 2006, at 8:09 PM, James Holderness wrote:
Thus, can atom be used to ship around parcels of xml snippets? I
suppose it
could, but only so long as both ends knew what was going on, and
knew naïve
atom processors might barf on the incomplete xml, right?
The one time I'd think it
On 17/1/06 2:21 AM, James Holderness [EMAIL PROTECTED] wrote:
the media resource is supposed to be stored external to
the collection feed and referenced via a content src link
hmmm ... premature optimisation due to common use case of binary content?
e.
* Antone Roundy [EMAIL PROTECTED] [2006-01-16 16:40]:
With type=xhtml, the data could just be dumped into the
webpage (after appropriate stripping of nasty tags and CSS and
such). With type=application/xhtml+xml, you'd have to figure
out to do with everything outside of the body element.
I
Eric Scheid wrote:
On 17/1/06 2:21 AM, James Holderness [EMAIL PROTECTED] wrote:
the media resource is supposed to be stored external to
the collection feed and referenced via a content src link
hmmm ... premature optimisation due to common use case of binary content?
Possibly. But
On 16 Jan 2006, at 4:59 pm, James Holderness wrote:
In theory, yes. In practice, no. Bare in mind that the 0.3 Atom
spec had type=application/xhtml+xml with basically the same
functionality as the current type=xhtml. Now since Atom 0.3 is
still a whole lot more widely used than Atom 1.0,
Graham Parks wrote:
On 16 Jan 2006, at 4:59 pm, James Holderness wrote:
Now since Atom 0.3 is still a whole lot more widely used than Atom 1.0,
you can be fairly sure than anyone that bothers to handle XML content at
all will be capable of handling type=application/xhtml+xml containing
On Jan 16, 2006, at 4:21 PM, James Holderness wrote:
For example, below are the results of some tests I've run on 15
aggregators. The tests included the use of a div tag as the root
element, a p tag as the root element, and an html tag as the
root element (i.e. a complete xhtml document).
per rfc4287 section 4.1.3.3
4. If the value of type is an XML media type [RFC3023] or ends
with +xml or /xml (case insensitive), the content of
atom:content MAY include child elements and SHOULD be suitable
for handling as the indicated media type. If the src attribute
Is this a valid atom entry?
entry
[...elided...]
summarya snippet of foo xml/summary
content type=application/foo+xml
foo:thing xmlns:foo=http://xmlns.com/foo/0.1/;
foo:nameKing George/foo:name
/foo:Person
/content
Eric Scheid wrote:
Is this a valid atom entry?
entry
[...elided...]
summarya snippet of foo xml/summary
content type=application/foo+xml
foo:thing xmlns:foo=http://xmlns.com/foo/0.1/;
foo:nameKing George/foo:name
/foo:Person
Eric Scheid wrote:
Is this a valid atom entry?
entry
[...elided...]
summarya snippet of foo xml/summary
content type=application/foo+xml
foo:thing xmlns:foo=http://xmlns.com/foo/0.1/;
foo:nameKing George/foo:name
/foo:Person
Elliotte Harold wrote:
No. It's not even well-formed much less valid.
I personally assumed that the /foo:Person was an unintended error..
after accounting for such, the example is valid.
- James
On 16/1/06 12:40 PM, Elliotte Harold [EMAIL PROTECTED] wrote:
No. It's not even well-formed much less valid.
ignore the typo.
e.
Eric Scheid wrote:
But I'm not so sure it's valid now, because of the SHOULD clause below:
per rfc4287 section 4.1.3.3
[snip]
Assume foo xml requires foo:basket as the root element. Is it valid to have
atom:content with foo:thing as the immediate child?
Hey, now you're changing the
Eric Scheid wrote:
But I'm not so sure it's valid now, because of the SHOULD clause below:
I suppose technically it is valid since a SHOULD is a recommendation not a
requirement, but you'd need a very good reason for not following that
recommendation.
For example, an OPML document
On 16/1/06 1:57 PM, James M Snell [EMAIL PROTECTED] wrote:
entry
...
entry type=whatever OPML's type is
opml:outline xmlns:opml=whatever.. ... /
/entry
/entry
Heh.. another typo methinks ;-)
grrr! TooEarly - SufficientCoffee = Typos
e.
On 16/1/06 2:09 PM, James Holderness [EMAIL PROTECTED] wrote:
The one time I'd think it might be safe is with XHTML (as I mentioned in a
previous message) since Atom processors are already required to handle XHTML
fragments in the content element. Anything else would be highly risky unless
Hi Eric,
* Eric Scheid [EMAIL PROTECTED] [2006-01-16 05:20]:
then you're not going to like what I was thinking of doing ...
posting atom:category / chunks to an APP/media collection,
such that the media collection entry might look like this (no
typos this time, I hope)...
entry
...
On 16/1/06 3:46 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Thus, in the same sense I might have elsewhere a collection of
images, I have here a collection of atom categories.
That doesn¹t even work, because this is invalid:
entry
!-- ... --
content
On 16 Jan 2006, at 3:09 am, James Holderness wrote:
The one time I'd think it might be safe is with XHTML (as I
mentioned in a previous message) since Atom processors are already
required to handle XHTML fragments in the content element. Anything
else would be highly risky unless it was a
Hi Eric,
* Eric Scheid [EMAIL PROTECTED] [2006-01-16 05:20]:
then you're not going to like what I was thinking of doing ...
posting atom:category / chunks to an APP/media collection,
such that the media collection entry might look like this (no
typos this time, I hope)...
entry
...
On 16 Jan 2006, at 6:50 am, A. Pagaltzis wrote:
okay, another thrust, taking into account the things you said in
your reply to the first thrust: is anything wrong with this?
entry
!-- ... --
content type=application/xml
category .../
/content
/entry
I aggree to this point
-Manoj
On Mon, 16 Jan 2006 11:59:48 +0530, Graham Parks
[EMAIL PROTECTED] wrote:
On 16 Jan 2006, at 3:09 am, James Holderness wrote:
The one time I'd think it might be safe is with XHTML (as I mentioned
in a previous message) since Atom processors are already
44 matches
Mail list logo
