On Feb 1, 2005, at 10:17 AM, Robert Sayre wrote:
We dropped multiple content elements months ago, with good reason. Two
of the more serious concerns were accessbility and the fact that
nobody uses them in Atom 0.3. As I understand it, the only reason they
were there originally was for uploading
On Feb 1, 2005, at 10:17 AM, Graham wrote:
There's an awful lot more to an aggregator than the 3 lines that pull
stuff out of XML. My problem is that users want to see the content in
their preferred language, which means I have to provide some mechanism
to choose, which may end up being the most
There's an awful lot more to an aggregator than the 3 lines that pull
stuff out of XML. My problem is that users want to see the content in
their preferred language, which means I have to provide some mechanism
to choose, which may end up being the most complex part of a simple
app. Additionall
Mark Nottingham wrote:
Using XPath as a yardstick, what's so complex about this?
/atom:feed/atom:entry[1]/atom:[EMAIL PROTECTED]'HTML'|@type='TEXT'][0]
I'm not even sure how I'd approach choosing between HTML and text in
the current approach, where one is in atom:content and the other is
referred
Using XPath as a yardstick, what's so complex about this?
/atom:feed/atom:entry[1]/atom:[EMAIL PROTECTED]'HTML'|@type='TEXT'][0]
I'm not even sure how I'd approach choosing between HTML and text in
the current approach, where one is in atom:content and the other is
referred to by atom:link; I'd n
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 misg
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:
>
> > Anonymous (from IP: aaa.bbb.ccc.)
>
> Well yes, and there's always:
>
>
> The title of this feed is "The Stuff" and the first entry
On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio <[EMAIL PROTECTED]> wrote:
> Anonymous (from IP: aaa.bbb.ccc.)
Well yes, and there's always:
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 content
"...
Wha
On 1/2/05 5:31 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
> Another option would be to allow one with inline content, and
> alternative content by reference, eg. (not being careful about getting
> language tags correct):
+1
On 1/2/05 6:02 AM, "Mark Nottingham" <[EMAIL PROTECTED]> 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
I thought atom:host was made redundant by the combination of HeadInEntry and
FeedLink...
bob wyman
On Jan 31, 2005, at 10:31 AM, Antone Roundy wrote:
Another option would be to allow one with inline content,
and alternative content by reference, eg. (not being careful about
getting language tags correct):
This is a pen
http://foo.com/abc"; />
http://foo.com/aiu"; />
I think that's the same
On Sunday, January 30, 2005, at 10:49 AM, Eric Scheid wrote:
On 31/1/05 3:47 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
+1, but not just type attributes, also xml:lang variations please.
-1. An Atom entry is *one* representation and you can link to
alternates.
I'm deeply unhappy that this was
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 fe
Robert Sayre wrote:
In the subscribe dialog, I always know what the appropriate agent is.
What makes you think "standards" dictate some other behavior?
Counter example: one that is all too common. If you get back something
with a content type of text/html, what you are probably getting back is
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 ra
* 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.
W
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
--
bytes GmbH --
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
If we don't want Atom to be processed by "generic XML processors and
technologies" and dispatched accordingly, then the correct course of
action would be to choose a media type without the "+xml" suffix. I
still don't see how this relates to atom:info.
Robert Sayre
Mark Nottingham wrote:
RFC 30
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 'solution'
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
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 t
On Sun, 30 Jan 2005 18:11:56 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> 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,
>
Good question. If it's served with Atom's media type, most (but not
all, I suspect) browsers will ask how to dispatch it, or just save the
file; some might optimistically try to handle it themselves, based on
the "+xml".
In the case that they dispatch it elsewhere (including the local
filesyst
Mark Nottingham wrote:
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 sel
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
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 in-s
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 to
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
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 Consider
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
re
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 interoperabilit
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 interoperability problems. I don't
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 i
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 interoperability problems. I don't see how applicati
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
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 and
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
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 the
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 t
Robert Sayre wrote:
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 chars
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 defi
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 wou
On 31/1/05 3:47 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> +1, but not just type attributes, also xml:lang variations please.
>
> -1. An Atom entry is *one* representation and you can link to alternates.
> I'm deeply unhappy that this was raised again. We went over and over on
> the matter
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:
* 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.
People use this h
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 atom:
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 mat
* 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 allo
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 t
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
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
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 a
54 matches
Mail list logo
