On 1/2/05 5:31 AM, Antone Roundy [EMAIL PROTECTED] wrote:
Another option would be to allow one content with inline content, and
alternative content by reference, eg. (not being careful about getting
language tags correct):
+1
On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio [EMAIL PROTECTED] wrote:
atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name
Well yes, and there's always:
atom
The title of this feed is The Stuff and the first entry it contains
is titled Hello World from 1st February, and that has the
On Tue, 1 Feb 2005 10:58:52 +0100, Danny Ayers [EMAIL PROTECTED] wrote:
On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio [EMAIL PROTECTED] wrote:
atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name
Well yes, and there's always:
atom
The title of this feed is The Stuff and the
On 31 Jan 2005, at 7:02 pm, Mark Nottingham wrote:
If the concern about multiple content is solely that it will result in
more bandwidth use, I think it's misplaced; people who are concerned
about bandwidth won't publish multiple representations inline; forcing
them not to by legislation is
Mark Nottingham wrote:
And, if you use XSLT, it's also possible to do it all in-stylesheet,
with or without links.
Safari (and probably other things) don't do XSLT.
Fair enough.
Safari is said to get a (libxml-based) XSLT engine in the next major
upgrade.
Best regards, Julian
--
green/bytes
* Robert Sayre wrote:
If I tell NetNewsWire to GET something in the subscribe dialog, my
dispatching instructions are clear. Everything is a feed. Making up
rules for application/xml, text/xml, and application/octet-stream will
require superceding some RFCs that I'd rather not mess with.
What
Bjoern Hoehrmann wrote:
* Robert Sayre wrote:
If I tell NetNewsWire to GET something in the subscribe dialog, my
dispatching instructions are clear. Everything is a feed. Making up
rules for application/xml, text/xml, and application/octet-stream will
require superceding some RFCs that I'd
Sam Ruby wrote:
Interoperability will be improved if we can nail down what are valid
media types that atom feeds can be served with, and what are invalid
media types that should always be rejected.
We can build voluntary conformance test suites for aggregator
developers to test against.
The
On Jan 31, 2005, at 10:31 AM, Antone Roundy wrote:
Another option would be to allow one content with inline content,
and alternative content by reference, eg. (not being careful about
getting language tags correct):
content type=TEXT xml:lang=en_USThis is a pen/content
content type=text/html
I thought atom:host was made redundant by the combination of HeadInEntry and
FeedLink...
bob wyman
A few comments as I read the latest draft; apologies if I've missed
relevant discussion, a pointer would be greatly appreciated in that
case.
* 3.1 Text Constructs -- Since the atom:content no longer references
this construct, my preference would be to remove this section
altogether and make
On 30 Jan 2005, at 7:48 am, Mark Nottingham wrote:
If so, why doesn't atom:author allow markup for the Person's name as
well? It would be odd, for example, to allow publishers to affect the
presentation of the title, but not the author's name.
Some people already use italics in their titles. Who
On 30/1/05 6:48 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
* 3.1 Text Constructs -- Since the atom:content no longer references
this construct, my preference would be to remove this section
altogether and make atom:title, atom:copyright, atom:summary,
atom:tagline and atom:info have simple
Eric Scheid wrote:
On 30/1/05 6:48 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
* 4.15 The atom:content Element -- I strongly believe that more than
one atom:content should be allowed; there are use cases when there are
multiple representations of the item, and it is useful and necessary to
* 4.15 The atom:content Element -- I strongly believe that more
than one atom:content should be allowed; there are use cases
when there are multiple representations of the item, and it is
useful and necessary to communicate this in the feed. I suggest
that multiple atom:content elements be
Mark Nottingham wrote:
My gut feeling is that removing the markup from these elements will
make the spec much simpler and easier to implement, without
sacrificing many (if any) use cases. If I'm not aware of someone's use
case here, I'm sorry and I'd love to hear about it.
It doesn't really
Anne van Kesteren wrote:
* 4.15 The atom:content Element -- I strongly believe that more
than one atom:content should be allowed; there are use cases
when there are multiple representations of the item, and it is
useful and necessary to communicate this in the feed. I suggest
that multiple
Sam Ruby wrote:
Robert Sayre wrote:
* 4.21 The atom:info Element -- If it's not considered meaningful
for processors, why does there need to be a standard element for it?
At the very least, some sort of information about its semantics
should be documented. My preference would be to drop it.
Robert Sayre wrote:
Sam Ruby wrote:
Robert Sayre wrote:
* 4.21 The atom:info Element -- If it's not considered meaningful
for processors, why does there need to be a standard element for it?
At the very least, some sort of information about its semantics
should be documented. My preference
Sam Ruby wrote:
Then I am clearly confused.
At the moment, the feedvalidator would mark an atom feed as invalid if
it were served with the text/plan, application/rss+xml, or
application/rdf+xml media types. It accepts as valid text/xml (if the
feed is either ASCII or a charset is explictly
Sam Ruby wrote:
I am still confused.
Transforming an Atom feed into another format does not result in a
valid Atom feed.
Right, but it's useful for the tranformation.
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
If
Robert Sayre wrote:
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
See the XML specification section F.2 [1]. It is quite possible for an
XML document to be valid if served with media type application/xml, but
for
Sam Ruby wrote:
Robert Sayre wrote:
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
See the XML specification section F.2 [1]. It is quite possible for
an XML document to be valid if served with media type
On Jan 30, 2005, at 9:07 AM, Robert Sayre wrote:
Mark Nottingham wrote:
My gut feeling is that removing the markup from these elements will
make the spec much simpler and easier to implement, without
sacrificing many (if any) use cases. If I'm not aware of someone's
use case here, I'm sorry
Mark Nottingham wrote:
...
+1
There may be good reasons for atom:host and atom:info to be there, but
they aren't really obvious by reading the spec alone.
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Big +1!
On Jan 30, 2005, at 12:34 PM, Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
result
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
result in
Julian Reschke wrote:
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
Robert Sayre wrote:
Mark Nottingham wrote:
* 4.11 The atom:host Element -- I'm surprised to see this in an IETF
specification; people are going to make bad assumptions about the
content of this, and violate layering to populate it. At the VERY
least, I'd expect to see text in Security
I'm not going to lie down in the road to get rid of atom:host, if there
are a lot of people that want it badly. However, it should be more
completely specified; i.e., some mention in security considerations,
and also, more information about the association.
Right now, it's just domain name or
OK. So, why is it necessary to standardise this element? Look at
http://www.mnot.net/test/atom.xml
which is the same feed, but with atom:info replaced by a 'foo' element.
Because the atom document has to reference the CSS anyway, it's
entirely reasonable to have the css specify what element
On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote:
which is the same feed, but with atom:info replaced by a 'foo' element.
Even better, you can drop foo and put the xhtml div as a direct child
of feed. Then use feed div as the selector.
And, if you use XSLT, it's also possible to do it all
On Jan 30, 2005, at 7:03 PM, Graham wrote:
On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote:
which is the same feed, but with atom:info replaced by a 'foo'
element.
Even better, you can drop foo and put the xhtml div as a direct child
of feed. Then use feed div as the selector.
Nice!
And, if
Mark Nottingham wrote:
So, the relevant question seems to be whether any browsers do something
interesting with +xml media types;
No, the relevant question is whether +xml media types can be reliably
dispatched without any knowledge of a specific scheme. I don't know the
answer, but I do know
RFC 3023, Section 7:
This document recommends the use of a naming convention (a suffix of
'+xml') for identifying XML-based MIME media types, whatever their
particular content may represent. This allows the use of generic
XML
processors and technologies on a wide variety of different
Joe Gregorio wrote:
I believe atom:host is the long lost descendent of atom:ipaddr, which came from
the problem I had implementing Atom on wiki, where the 'author' of an
entry can be difficult to pin down and the ip address may be the only
information available. If atom:host is what the
On Jan 30, 2005, at 8:09 PM, Robert Sayre wrote:
Yay! Let's drop atom:host.
+1 oh yes please, I always thought it was lame-ass. -Tim
37 matches
Mail list logo
