On 19 May 2005, at 23:02, Robert Sayre wrote:
On 5/19/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
Of course, breaking any link in my complicated chain of logic above
would cause the whole argument to collapse, which would be fine
with me.
Maybe the requirement is useless.
"If multiple atom:
On 21/5/05 4:24 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> So those are just a few thoughts on the topic. It just seems that if one
> works with the web these phishing problems seem to disappear.
all good stuff, with the exception of making atom:id dereferenceable... once
you do that you h
On 21/5/05 10:48 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> I don't see why, if you wanted that kind of archive, you couldn't use
> atom:updated for every little change in the archived version but
> atom:updated only for the ones you cared about in the published
> version. In which case the arc
On 21/5/05 1:26 PM, "Roger B." <[EMAIL PROTECTED]> wrote:
>>> change from a unicode combined char to single + combining
>>> diacritic,
>>
>> No.
>>
>>> change in paragraph 27 of an article that doesn't show up in a
>>> summaries-only feed,
>>
>> No.
>
> Dave: In my case, and seemingly in the
Tim Bray wrote:
> I think the WG basically decided to punt on the DOS scenario. -Tim
I believe you are correct in describing the WG's unfortunate
disposition towards this issue. (Naturally, I object...) In any case, given
that a significant DOS attack has been identified -- yet not address
On 18 May 2005, at 17:30, Antone Roundy wrote:
On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote:
I supposed the surest way to make it impossible to fake the id, is
to specify that
by dereferencing the id and doing a GET (whatever the correct
method of doing that for the
protoco
Tim Bray directs the editors to insert the following words:
"If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed document, they describe the same entry and Atom Processors
MUST treat them as such."
It is a long standing and valued tradition in the IETF th
On 21/5/05 9:40 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> 1. The datestamp is inserted by the provider. Thus it could be a lie;
> this is the Internet, remember. You, the consumer, either trust the
> publisher or you don't. If you don't, you will ignore the datestamp
> and check the content.
Graham wrote:
> What if someone (either the publisher or someone downstream)
> wants to store a history of every revision in an archive
> feed?
To this, Tim Bray answered:
> I don't see why, if you wanted that kind of archive, you couldn't
> use atom:updated for every little change in the archive
> > change from a unicode combined char to single + combining
> > diacritic,
>
> No.
>
> > change in paragraph 27 of an article that doesn't show up in a
> > summaries-only feed,
>
> No.
Dave: In my case, and seemingly in the case of most of the tools
surveyed, both of those would get a "yes".
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 adjust the
atom:update
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 adjust the
> atom:updated by one second and put both in the re
On 21 May 2005, at 1:48 am, Tim Bray wrote:
I don't see why, if you wanted that kind of archive, you couldn't
use atom:updated for every little change in the archived version
but atom:updated only for the ones you cared about in the published
version. In which case the archived version would
[reposted without so many typos and grammatical errors - reply to either]
As I was the last person to mention atom:modified, I'll refer to my
proposal as an example in this reply.
> 1. The datestamp is inserted by the provider. Thus it could be a lie;
> this is the Internet, remember. You, th
On May 20, 2005, at 11:29 AM, Bill de hÓra wrote:
http://www.franklinmint.fm/blog/archives/000393.html
"The Atom author element may be inadequate for scientific journals,
legal documents, and legislation. I am shocked, just shocked."
Translation: The Atom format mandates you can only have one aut
On May 20, 2005, at 5:07 PM, Graham wrote:
Tim, can I ask about your thinking regarding the use of atom:updated
in PaceDuplicateIDs. What if someone (either the publisher or someone
downstream) wants to store a history of every revision in an archive
feed? atom:updates forces one to choose only
As I was the last person to mention atom:modified, I'll refer to my
proposal as an example in this reply.
> 1. The datestamp is inserted by the provider. Thus it could be a lie;
> this is the Internet, remember. You, the consumer, either trust the
> publisher or you don't. If you don't, you
On May 20, 2005, at 12:00 AM, Thomas Broyer wrote:
In 4.1.3.2:
[
If the value of type begins with "text/" or ends with "+xml", the
content SHOULD be local; that is to say, no "src" attribute should
be
provided.
]
Replace with:
[
If the value of type is a text or XML media type, that
On May 19, 2005, at 1:38 PM, Sam Ruby wrote:
... MUCH text elided ...
This proposal seemed to have enjoyed some support, yet it did not seem
to have made it into the current draft, despite being crucial to the
solving the issue that PaceDuplicateIDs was designed to address.
However, for it to wo
On May 19, 2005, at 12:40 PM, Robert Sayre wrote:
Paul and I consider that the following text has consensus support of
the WG and the editors are directed to include it in the format draft
(editorial judgment call on where to insert):
Some applications (one example is full-text indexers) require a
On May 19, 2005, at 12:58 PM, Robert Sayre wrote:
I don't think we ever resolved this last call issue.
http://www.imc.org/atom-syntax/mail-archive/msg14383.html
Tim Bray wrote:
OK, WG, what do you think? I have long supported the SHOULD here, but
I can't help observing that a lot of different parti
Tim, can I ask about your thinking regarding the use of atom:updated
in PaceDuplicateIDs. What if someone (either the publisher or someone
downstream) wants to store a history of every revision in an archive
feed? atom:updates forces one to choose only one version per
"significant" change.
On May 19, 2005, at 12:43 PM, Robert Sayre wrote:
---
The editors are directed to modify
the phrase which starts "If multiple atom:entry elements..." as
follows:
"If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed document, they describe the same entry an
On May 19, 2005, at 12:36 PM, Robert Sayre wrote:
On 5/19/05, Tim Bray <[EMAIL PROTECTED]> wrote:
(Text not
provided, we trust the editors to figure out the correct way to say
this).
The editors request that text be provided.
In section 4.1.1, change the bullet point that reads
atom:feed elemen
I'm engaged in trying to convince a large well-known organization to
take Atom seriously (I think I'm winning) and we had this email
exchange, which I thought might be useful as a refresher for those who
have blissfully forgotten the great updated/modified debate.
===
Friday, May 20, 2005, 8:02:49 PM, Paul Hoffman wrote:
> Does the WG want to be able to open up new topics, or re-open old
> topics with a twist? If so, do we all agree to the delay in
> publication that comes with that?
What would the minimum delay be out of interest? 4 weeks? 6 weeks?
> A
On 5/20/05, Graham <[EMAIL PROTECTED]> wrote:
>
> On 20 May 2005, at 8:02 pm, Paul Hoffman wrote:
>
> > Does the WG want to be able to open up new topics, or re-open old
> > topics with a twist? If so, do we all agree to the delay in
> > publication that comes with that? Also, how long should th
FYI:
Robert Scoble, a Microsoft employee/insider very familiar with Microsoft's
plans for syndication, declares in comments on his blog that "we are
supporting Atom in any aggregator we produce." Microsoft's example in
supporting Atom should be followed by all other aggregator developers in the
f
--On Tuesday, May 17, 2005 09:13:37 PM -0700 Tim Bray <[EMAIL PROTECTED]> wrote:
PaceCaching
Multiple -1's, it fails.
I'll address the objections anyway, because I (still) think this is
important.
1. This introduces multiple caching schemes.
Wrong. Right now we have multiple schemes, with HTTP cac
On 20 May 2005, at 8:02 pm, Paul Hoffman wrote:
Does the WG want to be able to open up new topics, or re-open old
topics with a twist? If so, do we all agree to the delay in
publication that comes with that? Also, how long should this
opening and re-opening last? Are there any limits on which
On 21/5/05 5:02 AM, "Paul Hoffman" <[EMAIL PROTECTED]> wrote:
> HOWEVER, since it is clear that many people in the WG want to
> continue to add or change technical features in the document,
> we need to decide NOW what the process should be.
maybe it's time for all of us to take the draft we hav
Wearing my co-chair hat:
We had a WG Last Call. It brought out a lot of issues, and we dealt
with each of them (not always to the satisfaction of the person who
brought up the issue, of course).
We had an IETF-wide Last Call. It brought out a lot of issues, and we
dealt with each of them (not a
* Eric Scheid <[EMAIL PROTECTED]> [2005-05-20 19:55]:
> > 6.4ÂExtension Elements
> >
> > Atom allows foreign markup anywhere in an Atom document.
>
> does this mean this is allowed:
>
> hello world!:-)
You request adding âexcept where they are explicitly forbiddenâ
to that sentence, I supp
* Eric Scheid <[EMAIL PROTECTED]> [2005-05-20 20:10]:
> On 21/5/05 3:41 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> > However, it does pose a problem of default semantics. Do we
> > define particular categories in the spec? If we donÂt, do we
> > define a default category to be assumed in abse
--On Friday, May 20, 2005 09:33:01 AM -0400 Robert Sayre <[EMAIL PROTECTED]> wrote:
Those are three terrible use cases. Shall we go through every element
in the format and evaluate their fitness for scientific journals,
legal documents, and legislation?
Here is a list of 341 scientific journals wit
On 21/5/05 4:17 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> Well unless we make category/term machine readable, we might as well
> just have a plain text blob.
it is machine readable:
http://www.loc.gov/marc/sourcecode/relator/relatorlist.html
term="aut"
label="Author"
/>
they also defin
* Graham <[EMAIL PROTECTED]> [2005-05-20 20:30]:
> Well unless we make category/term machine readable, we might as
> well just have a plain text blob.
But we already did that. Thereâs an option @scheme attribute for
atom:category. Thatâs part of the elegance of this approach.
Regards,
--
Aristo
http://www.franklinmint.fm/blog/archives/000393.html
"The Atom author element may be inadequate for scientific journals,
legal documents, and legislation. I am shocked, just shocked."
Translation: The Atom format mandates you can only have one author, for
an entry or a feed.
Why is this not a s
On 5/20/05, Danny Ayers <[EMAIL PROTECTED]> wrote:
> I would think the need to assign different statuses to the
> author/contributors (and corresponding labelling) will be a rarity
> compared to what's covered by allowing multiple authors.
Here is a new example for the spec. Is there a use case t
>> Does anyone remember the reason we have atom:contributor? I say drop it.
this is instructive reading...
http://www.intertwingly.net/wiki/pie/NumberOfAuthorsDiscussion
> If we do allow multiple s, we could ditch and at
> the same time lessen the likelihood of ugliness like:
>
> Ragge
On 20 May 2005, at 6:19 pm, Eric Scheid wrote:
actually, I'm liking this more and more, because...
Barnable Foo
<.../>
Well unless we make category/term machine readable, we might as well
just have a plain text blob.
Graha
On 21/5/05 3:41 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> However, it does pose a problem of default semantics. Do we
> define particular categories in the spec? If we don¹t, do we
> define a default category to be assumed in absence of explicit
> category elements in the document? If we do
On 5/20/05, Graham <[EMAIL PROTECTED]> wrote:
> Does anyone remember the reason we have atom:contributor? I say drop it.
Good question (I can't remember - was feed-level attribution a
consideration?). Looking at it now the primary author/secondary
contributors thing seems open to technical clunk
did someone say that the spec doesn't use the word "software"?
> 6.3 Software Processing of Foreign Markup
e.
> 6.4 Extension Elements
>
> Atom allows foreign markup anywhere in an Atom document.
does this mean this is allowed:
hello world!:-)
e.
* Eric Scheid <[EMAIL PROTECTED]> [2005-05-20 17:50]:
>
>
> Barnable Foo
> <.../>
>
+1
Very elegant.
As for the inheritance problem this does bring up: the current
spec implicitly defines that no inheritance from the feed takes
place when a
On 21/5/05 1:35 AM, "Eric Scheid" <[EMAIL PROTECTED]> wrote:
>
>
> Barnable Foo
> <.../>
>
actually, I'm liking this more and more, because...
Barnable Foo
<.../>
(Just in cas
On 21/5/05 12:36 AM, "David Powell" <[EMAIL PROTECTED]> wrote:
> A risk of allowing multiple atom:author elements is that it might
> break the feed/entry inheritance thing: does atom:entry/atom:author
> override or merge with atom:feed/atom:author? I suppose a FOAF block
> could be included as
On 21/5/05 12:49 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> Right now, the spec reads as if there is one primary person, and then
> a bunch of contributor minions. The example also makes it look that
> way. Maybe we could adjust it to make atom:author a 'primary field'
> and then atom:contri
On 20 May 2005, at 4:12 pm, Robert Sayre wrote:
Well, the two examples we've been shown want to control presentation
when multiple authors are grouped.
"Raggett, D, Hors, A, and I Jacobs"
"Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen"
The logical answer would then be a new element for that
On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> Robert Sayre wrote:
> > On 5/20/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I really don't want to see this in an Atom feed:
> >>
> >>Raggett, D, Hors, A, and I Jacobs
> >
> >
> > *gasp. multiple nouns inside a single element.
Robert Sayre wrote:
I meant
Yuri Fialko, David Sandwell, Mark Simons & Paul
Rosen
http://research.example.org/dept/
Yuri Fialko
http://research.example.org/dept/fialko/
David Sandwell
http://research.example.org/dept/sandwell/
Mark Simons
http:
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > Right now, the spec reads as if there is one primary person, and then
> > a bunch of contributor minions. The example also makes it look that
> > way. Maybe we could adjust it to make atom:author a 'primary field'
> > and th
* Ben Lund <[EMAIL PROTECTED]> [2005-05-20 15:04+0100]
>
> Robert Sayre wrote:
> >On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> >
> >>Eric Scheid wrote:
> >>
> >>
> >>>Science Journals are just one example of feeds which require being able
> >>>to
> >>>specify multiple authors per entry.
Robert Sayre wrote:
Right now, the spec reads as if there is one primary person, and then
a bunch of contributor minions. The example also makes it look that
way. Maybe we could adjust it to make atom:author a 'primary field'
and then atom:contributor could break each entity. So, Ben's example
woul
On 5/20/05, David Powell <[EMAIL PROTECTED]> wrote:
>
> Perhaps the definition of atom:name should be tweaked to make it a
> label for the Person construct. atom:name sounds too much like a
> singular name of a person or company.
Hmmm. That's true. There also seems to be a stigma attached to
ato
On Fri, May 20, 2005 at 10:09:07AM -0400, Robert Sayre wrote:
> > Given that this is a need for this (see [3] for an example of how we
> > currently choose to deal with this in RSS 1.0), what other rationale is
> > there for not having multiple authors?
>
> We better do something about that from
Friday, May 20, 2005, 3:09:07 PM, Robert Sayre wrote:
> I'm not dismissing them. I'm saying they should use an extension,
> which they'll be needing anyway.
The important thing is that we should make sure that they can use an
extension to do this. The current wording for Person construct might
Robert Sayre wrote:
On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Legal documents and legislation are others. Good catch Eric. I'll
support this.
Those are three terrible use cases.
Let's suppose there's general agreement here with that opinion. The
things to ask here nonetheless are
a)
Robert Sayre wrote:
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote:
Given that this is a need for this (see [3] for an example of how we
currently choose to deal with this in RSS 1.0), what other rationale is
there for not having multiple authors?
[3] http://www.nature.com/nature/current_issue/rss
Joe Gregorio wrote:
> To be completely accurate, the part before the '/' is called the type,
> the part after the '/' is called the sub-type
I know.
I chose not to use these terms to make the wording "lighter" and thus
easier to read and understand.
--
Thomas Broyer
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote:
> Given that this is a need for this (see [3] for an example of how we
> currently choose to deal with this in RSS 1.0), what other rationale is
> there for not having multiple authors?
>
> [3] http://www.nature.com/nature/current_issue/rss
Ooh. Act
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> >
> >>Eric Scheid wrote:
> >>
> >>
> >>>Science Journals are just one example of feeds which require being able to
> >>>specify multiple authors per entry.
> >>
> >>Legal
Robert Sayre wrote:
On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Eric Scheid wrote:
Science Journals are just one example of feeds which require being able to
specify multiple authors per entry.
Legal documents and legislation are others. Good catch Eric. I'll
support this.
Those are thre
On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> Eric Scheid wrote:
>
> > Science Journals are just one example of feeds which require being able to
> > specify multiple authors per entry. I have Library clients who want to make
> > their indexing efforts available in XML form - currently
On 5/20/05, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
>
> I'd like to raise this up one more time:
> http://www.imc.org/atom-syntax/mail-archive/msg14247.html
>
> Atom defines rules based on MIME media types in @type attributes, and I'm
> not sure they are actually accurate...
> They also don'
On 20/5/05 9:51 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> Raggett, D, Hors, A, and I Jacobs
>
> *gasp. multiple nouns inside a single element.
>
> I don't see why that's a problem.
Try then importing those article feeds and producing an a-z index by author.
e.
Robert Sayre wrote:
On 5/20/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
I really don't want to see this in an Atom feed:
Raggett, D, Hors, A, and I Jacobs
*gasp. multiple nouns inside a single element.
*gasp. multiple nouns inside a single noun element.
I don't see why that's a problem. For ex
On 5/20/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
> I really don't want to see this in an Atom feed:
>
> Raggett, D, Hors, A, and I Jacobs
*gasp. multiple nouns inside a single element.
I don't see why that's a problem. For example, you wouldn't be able to
recreate that string from three
On 20 May 2005, at 4:41 am, Eric Scheid wrote:
I have Library clients who want to make their indexing efforts
available in XML form - currently I can recommend RSS
1.0, but I would like to be able to recommend Atom 1.0 when it becomes
available. With a one-author-per-article restriction this wou
Robert Sayre wrote:
-1. This is an edge case, and one that's not covered by RSS 1.0, btw.
Dublin Core elements make perfect sense in an Atom feed.
DC elements makes sense, but we have consistently chosen not to use
them. So, if consensus is that it's not an edge case, then that would
argue in fav
Eric Scheid wrote:
Science Journals are just one example of feeds which require being able to
specify multiple authors per entry. I have Library clients who want to make
their indexing efforts available in XML form - currently I can recommend RSS
1.0, but I would like to be able to recommend Atom 1
On 5/19/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
> Science Journals are just one example of feeds which require being able to
> specify multiple authors per entry. I have Library clients who want to make
> their indexing efforts available in XML form - currently I can recommend RSS
> 1.0, but I
> >>If we do allow multiple authors, we might want to put a warning in that
> >>consuming applications MAY ignore some of them if more than one is
> >>supplied. As long as we do that, and perhaps even if not, I'd be in
> >>favor of allowing more than one.
+1 from me as well, from the Wiki perspe
Eric Scheid wrote:
On 20/5/05 2:10 PM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
If we do allow multiple authors, we might want to put a warning in that
consuming applications MAY ignore some of them if more than one is
supplied. As long as we do that, and perhaps even if not, I'd be in
favor of
I'd like to raise this up one more time:
http://www.imc.org/atom-syntax/mail-archive/msg14247.html
Atom defines rules based on MIME media types in @type attributes, and I'm
not sure they are actually accurate...
They also don't explain the actual meaning behind the technical rules.
In 4.1.3.2:
76 matches
Mail list logo
