On 24 Jan 2006, at 10:55 pm, James M Snell wrote:
Thoughts?
It's either not going to be used or will be abused when it is. I
can't see it ending well.
Graham
n of double checking and/or loading the resource anyway.
Graham
ries is preferable?
The correct thing to do is to pick the one provided by default by the
server when no content negotiation occurs. eg:
http://www.example.com/img"; />
Graham
tor can only check whether something
is syntactically correct. It cannot check whether it's semantically
correct (ie means what you think it means). I'm sure you know this
and are just being an asshat.
Graham
. Atom is unambiguous. "application/xhtml+xml"
means the page content is a full standalone web page.
Graham
meaningless, since category Atom documents
aren't defined anywhere.
2) Invalid, since category Atom documents aren't defined anywhere.
Graham
was a proprietary feed
communicating between two known applications.
Except no one bothered to tell the aggregator writers they'd have to
implement this, so no it's not safe.
Graham
On 9 Jan 2006, at 9:33 pm, A. Pagaltzis wrote:
http://.../tag";
term="?tag=foo"
label="foo"
/>
Blurgh.
Graham
.
Point to any text in the spec that backs this up.
Graham
alidator admitted it's fallibility and
said straight up that it doesn't know if these are problems or not.
Graham
that's probably better left to aggregator developers to
implement as a feature.
Another feature is the list can be formatted properly XHTML,
considerably improving legibly over a bunch of floating entries.
Graham
is as a newswire of
recently posted or updated entries, which works pretty well. For the
netflix queue to work, you have to take a step beyond that and view
the feed file as a document and not just an envelope. It's not
necessarily a hack, but it's a totally different paradigm.
Graham
m were flexible enough to cope where there
isn't a 1:1 mapping between publications and items of information, by
subdividing entries into chapters or something, but as Mark Pilgrim
said somewhere, Atom deals with none of the interesting problems with
syndication (Atom = RSS3).
Graham
preserve order.
Graham
ck robots.txt before downloading
images?
Graham
and information about the document's logical structure
to the application in the normal way)."
Graham
Just out of interest, how well does any of this work with caches and
proxies?
Graham
Rar!
On 17 Aug 2005, at 6:35 pm, Bob Wyman wrote:
This is excellent news! Finally, we have an openly and formally
defined
standard for syndication. Wonderful!
bob wyman
r me, this paragraph talks about the
*Atom
Document* moving, rather than the content that it represents (i.e.
a blog)."
Perhaps we could add "or its associated resource" after "Atom Document"?
Graham
On 12 Aug 2005, at 2:52 pm, Tim Bray wrote:
On Aug 12, 2005, at 1:55 AM, Graham Parks wrote:
"categorization scheme" means the system used to categorize
entries. Presumably each blog has its own system for doing so, so
the scheme attribute should be the same for all posts from
hat identifies a
categorization scheme."
"categorization scheme" means the system used to categorize entries.
Presumably each blog has its own system for doing so, so the scheme
attribute should be the same for all posts from the same blog, and
unique to the blog.
Graham
7;t describe an interoperable model. Either all processors
must remove whitespace, or whitespace is not allowed at all (Note the
latter still allows processors to remove whitespace anyway).
Graham
On 3 Aug 2005, at 2:04 pm, Sam Ruby wrote:
A note that Atom processors may consider leading and trailing space as
significant in attribute and element values would be enough to alert
people to the interoperability issues.
+1
Graham
wouldn't object to any text warning
people not to do it, or explicitly mentioning that you have to call
the equivalent of String.trim().
Recommending the former would draw attention to the issue and perhaps
encourage the latter. (Or make both explicit, with SHOULD and MAY).
Graham
This is
perhaps a bigger problem.
Graham
probably others) have already put code out into the wild in
the assumption there is no whitespace. As I said before, it's too
late for a solution that changes the meaning of the spec.
Graham
should be allowed around any machine-read content
(uris, @type, @rel, etc).
Graham
ise?
(oh, apparently because the feed validator is broken)
Graham
"src", but it is not expanded to "source" anywhere else in the document.
Graham
t enough to think of this problem and come
up with a better system or a workaround?
is simply appended to the beginning of the no-colon name:
http://www.w3.org/2005/Atomfeed
I'm off to start the Atomf working group which will produce a
standard specification for eed documents.
Graham
www.w3.org/2005/Atom";>
represents the element "feed" in the namespace "http://www.w3.org/
2005/Atom", and nothing else. There's no way of merging them.
Graham
05/Atomfeed
- http://www.w3.org/2005/Atomtitle
Exactly which part of the XML namespaces spec backs up this behaviour?
Graham
On 30 Jul 2005, at 1:38 am, A. Pagaltzis wrote:
* James M Snell <[EMAIL PROTECTED]> [2005-07-30 01:40]:
It's really just a hint as to where original entries MIGHT be
found.
“originally-at?”
source?
Graham
y may end up using an illogical encoding method.
I don't necessarily support this arrangement, but it's definitely far
superior to what we had before where the publisher could choose any
method which made decoding at the client tremendously complicated.
Graham
non-error result from the
error result.
The HTTP code?
Graham
I might see where Graham is coming from. Graham are you talking a case
where the feed/entries are being elided with not-available messages?
I think so. The problem with using HTTP error codes is that in many
clients the result is far less pretty. For example, in Shrook you get
a warning
(RSS guid "http://www.feedster.com/";), and I think
served with
HTTP status 200. This seems the wrong behavior for so many reasons.
What should they be doing in Atom?
And what should the client do?
(assuming a rich client that keeps an archive of entries)
Graham
think
served with HTTP status 200. This seems the wrong behavior for so
many reasons. What should they be doing in Atom?
Graham
On 21 Jul 2005, at 7:29 pm, James Cerra wrote:
Graham,
Yes, but your proposed solution just requires people at the other end
of the chain to do the hard work. A common theme in the design of
Atom is minimizing the amount of work that must be done by publishers
(of which there are many) vs
asier to turn into
common libraries).
Graham
less identifier.
OTOH, is there a reason that atom:uri (which should be
atom:indentifier) and
atom:email are not attributes of a person construct?
To allow easier, consistent extension.
Graham
actual document.
Graham
rmediaries corrupt IDs in exactly the right way.
Good luck with that.
Meanwhile, all new postings to my blog will have the ids
differentiated by varying the capitalization of the hostname, and
nothing else.
Graham
s ludicrous and arbitrary.
Graham
e
rest of the document.
Graham
On 16 Jul 2005, at 11:27 am, Graham wrote:
Also:
"Solution: Use the canonical form, given in the warning message."
It now says:
"All newly issued ids should be in canonical form. Use the canonical
form given in the warning message for guidance."
(http://feedvalida
ting changing permanent identifiers? Bad Sam.
ID canonicalization was a bloody stupid idea.
Graham
Why does the validator apparently fail outright when SHOULD level
requirements are ignored? This seems unnecessary in light of having a
spec where conformance levels are clearly defined.
Graham
lid, though it's hard to tell without a validator or
even a parser. I'm currently rewriting the engine of Shrook to be
compatible too.
(You may also notice I'm doing my little bit to make sure atom:id is
implemented properly)
Graham Parks
is to use to
reference the messages.
-1 to the proposal, at least for this use case.
Graham
ferent from the usual
meaning of those words, and may be misunderstood. It might be
better to say "Atom Processors MAY use the IRI to retrieve the
content, and MAY process or present remote content in a different
manner from local content."
+1
"and MAY process or present remote content in a different manner to
local content"
Graham
nd I
don't see how Atom would benefit from becoming a jack of all trades.
Graham
up to support
it, sadly.
Graham
body of the message is preserved end-to-end.
Graham
specifically to attacks where the main objective is
to prevent a service being accessible. Replacing content does deny
service, yes, but it's also a lot more than that.
Graham
entries originated
from the same publisher before considering them to be duplicates.
How is this a "Denial of service" attack? Isn't it just ordinary
spoofing/impersonation?
Apart from that, +1.
Graham
ngless goes way, way too
far.
(Also, do we have a definition for "Atom feed" that exists beyond a
single instance of a "feed document"?)
Graham
mailto: uri?
+1 to replacing atom:email and atom:uri with multiple real atom:link
elements (to allow titles).
(I don't care about the rel value)
Graham
-1 to "atom:link" unless they are proper link elements. I'm fairly
happy with the current situation.
Graham
hrown data away. Whether the change is significant or
not isn't important. As a user, I expect to be able to type something
in at one end and have it reliably appear in the same form,
regardless of what I type, or whether Thomas Broyer thinks the change
didn't matter.
Graham
On 24 May 2005, at 7:08 pm, David Powell wrote:
Whether the draft allowed it or not, atom:link isn't an extension
point. That would be Section 6.3 style "unknown foreign markup".
Unless there's a memo I missed, extensions are a subset of "unknown
foreign markup".
Graham
es it unclear that the
element is normally empty.
Graham
y allowing extension
elements in a place most people (such as Paul and myself) assumed
they weren't.
Graham
On 24 May 2005, at 9:40 am, Henri Sivonen wrote:
On May 23, 2005, at 12:31, Julian Reschke wrote:
For the record: I am +1 on <http://www.intertwingly.net/wiki/pie/
PaceOptionalXhtmlDiv>.
-1, and additionally I don't think the Pace is even complete or
reliably implementable.
Graham
uires atom:title and atom:updated, etc. I
guess we could add "All required feed metadata elements MUST be
present". OK?
I think the thing it's missing is "All elements MUST be copied when
creating an atom:source from an atom:feed"
Graham
This is invalid, since it has no root element. It represents the
standalone XML document:
<?xml version="1.0?>
<tag />
This is correct:
Graham
d say it draws from atom:source OR atom:feed. atom:feed should not
be used if atom:source exists, even if it doesn't contain an
atom:author, which it SHOULD.
(unrelated question: what's with this plus sign " & atomLink+" in the
atom:source production?)
Graham
name of a Creator should be used to indicate
the entity.)
The WG consensus in supporting multiple atom:authors seems to be
against having a singular creator, so -1 on this change.
Graham
On 23 May 2005, at 6:52 pm, Tim Bray wrote:
I suspect most people would guess right, and a culture of doing the
right thing would develop.
Dave, impersonating Tim like this is not on.
Graham
someone does (b)? Or if the
answer is (b), does someone else doing (a) imply that that author
contributed nothing? Implementers need to know this stuff.
Graham
d make sense to list her as a contributor as
well.
Why? She's already credited as the author. If you can explain why
that isn't completely redundant and confusing to software, a gold
star to you.
Graham
On 23 May 2005, at 4:58 pm, Tim Bray wrote:
Uh, Graham, I thought your Pace did a good job of capturing the
consensus that seems to be emerging, and then slipped in just a
little extra with the name-duplication rules. I'm with Rob, that
stuff is past the 80/20 point, I'd sugges
;This
entry was written by Anne Rice and Howard Allen O'Brien". Without the
restriction, all it can conclude is "The names Anne Rice and Howard
Allen O'Brien are in some way related to the authorship of this entry"
Graham
be) listed as both an author and a contributor (ie a author is by
definition a contributor). Does anyone object to that?
Graham
t be decodeable programatically,
unless you can provide psuedocode that proves otherwise.
Graham
t may be formatted
differently). It is impossible to do this with 100% reliably. Hence
the SHOULD NOT.
Graham
mentioned more than once.
Anything looser makes it very hard to interpret the intended meaning
of a set of atom:author and atom:contributor elements
programmatically. Please describe a suitable algorithm if you wish to
remove this constraint.
Graham
http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor
== Abstract ==
Allow multiple authors. Clarify relationship between atom:author and
atom:contributor.
== Status ==
Open
== Rationale ==
The current draft only allows one atom:author per entry, meaning either:
- All authors
encountering these situations?
See section 4.1.3.3 Processing Model
Does that mean that if you use "application/xhtml+xml", you can do
(rest of feed omitted for brevity):
Yes. This is why we have a special XHTML mode for fragments.
Graham
, the obvious way.
The idea that atom:autho and atom:contributor are independent is just
about a valid reading but completely counter-intuitive. There is a
problem here.
Graham
nd no, Robert, it doesn't matter that you apparently are sure)
Graham
to trust one of the sources more than the
other. If so, choose that. If not, apply the a policy such as
discarding any entries whose ID you've seen unless the atom:updated
is later than what you've seen so far. -Tim
Yes, but why? Why not allow both versions to travel downstream?
Graham
om lots of elements. Your impression is not in the spec.
I just about grasp what you're saying here. I certainly do not think
it's the obvious model from the spec, or an obvious model to most
people.
I do think you're right about the wording of atom:author, though.
Good.
Graham
On 21 May 2005, at 3:30 pm, Robert Sayre wrote:
On 5/21/05, Graham <[EMAIL PROTECTED]> wrote:
The appropriate way to decode this is "Written by Graham with
contributions from Friend 1 and Friend 2"
Lets decode your sample in the same way: "Written by Yuri Fialko,
David
On 21 May 2005, at 3:11 pm, Robert Sayre wrote:
On 5/21/05, Graham <[EMAIL PROTECTED]> wrote:
You can say that about anything. A flat list of people associated
with an entry is infinitely better than the weird one author/multiple
contributors model that doesn't offer a clear way t
domain to another.
The feed becomes a redirect and the aggregator can reliably compare
ids across the old and new addresses. Not hard.
Graham
rences, is that allowable.
What should a client that implements "the typical behavior ... to
display only the entry with the latest atom:updated timestamp" do?
Graham
fine.
Graham
of people associated
with an entry is infinitely better than the weird one author/multiple
contributors model that doesn't offer a clear way to cope with the
common model of multiple co-authors.
Graham
On 21 May 2005, at 2:15 am, Robert Sayre wrote:
On 5/20/05, Graham <[EMAIL PROTECTED]> wrote:
Say I'm aggregating feeds into a search results feed, and I get the
same entry twice (with the same atom:id and atom:updated), from
different sources. Would it be acceptable to me to
t's OK, but it certainly isn't
elegant.
Graham
ot; change. The mechanism it affords (being able to
automatically display the newest version) is vital, but it doesn't
seem like the best way to do it.
Graham
like duplicate IDs, but
everything else seems finished. I think there will be a natural
ending soon enough.
Graham
n text blob.
Graham
uld then be a new element for that label when
multiple atom:authors are present.
Does anyone remember the reason we have atom:contributor? I say drop it.
Graham
would be
impossible.
The one author restriction isn't really necessary. My only problem is
with our "order is not significant" rule since there's a strong
likelihood that authors will be displayed in the the order they
appear in the XML, and that publishers will expect it.
Graham
esent they shouldn't be empty. The other part of this text, that
summary be present when content isn't, can then be separated out for
the sake of clarity.
Otherwise, it's fine.
Graham
7;s the
version from Site B". That was kind of the idea of
PaceDuplicateIDWithSource. Of course, the atom:source element is as
fakeable as the entry's id. The only reliable origin is the URI it
was directly fetched from.
Oh, and compulsory feed:ids are fine with me. Certainly better than
the hybrid proposals.
Graham
only feeds? And why
wouldn't a TiVo or a cellphone want summaries? They have big screens
and decent storage space, and the data transfer overhead is pretty
negligible, and should be handled by a gateway if the pipe is that
narrow.
Graham
s" (and/or "fail")?
Graham
1 - 100 of 356 matches
Mail list logo
