FotoNotes extension (was: AtomPubIssuesList for 2005/02/22)

[Robert Sayre]

Paul Hoffman wrote:
This is also a reasonable time to start creating format extensions  and 
talking about them here.
Here's one that's sort of done:
http://fotonotes.net/spec/index.cgi?FotoNotesSpecification
This is what will carry Flickr annotations, and they do it with Atom and 
RDF. They made a few mistakes. One of them centered around the purpose 
of atom:id. That means *smart people miss the point*, because it's a 
subtly different than RSS. I think starting the example atom:id with 
"urn:uuid" instead of "vemmi://"; would help quite a bit.

Robert Sayre

FW: [rss-media] Coexistence with Atom ?

[Bob Wyman]

The following message was on the RSS-Media
group at:

http://groups.yahoo.com/group/rss-media/

It seems reasonable to expect that users
will expect that Atom and RSS-Media will, in fact, be used in concert in the
future.









From: ecomputerd
[mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 22, 2005
11:16 PM
To: [EMAIL PROTECTED]
Subject: [rss-media] Coexistence
with Atom ?



 

Has anyone reviewed how rss-media will coexist with Atom? I would 
imagine that
Atom along with rss-media will be the next 
specifications
that RSS client developers will need to implement 
(for those
that haven't already).

As a related
note, is there any way to include rss-media as a part 
(or subset)
of Atom.

I apologize
for not bringing this up earlier, it seems like we could 
reduce the
effort expended by developers if these specifications can 
coexists--or
be merged, for that matter.

Greg Smith
Author,
FeederReader - The Pocket PC RSS reader and podcatcher
Catches
video, too!
www.FeederReader.com

RE:

[Bob Wyman]

Martin Duerst wrote:
> Are you talking about the type attribute (as Sam and others have
> pointed out, that's no longer required) or the rel attribute.
I was primarily concerned about the type attribute since I hadn't
realized it was now optional. Thanks to Sam, etc. for pointing out that it
is no longer required.

bob wyman

Re:

[Martin Duerst]

(BAt 04:31 05/02/23, Bob Wyman wrote:
(B>At PubSub, we allow users to subscribe to RSS/Atom entries that contain 
(B>user-specified URIs. (Using a query like: URI:nytimes.com) Users of this 
(B>feature have often asked us to augment the entries we publish by attaching 
(B>the URIs we discover to the entries. The idea has been to make it easier 
(B>for people to build applications that exploit these links and to avoid 
(B>forcing clients to parse the full source entries.
(B>
(B>So, we$BCW(Be started adding these $BEM(Binks to URIs$BG
(Bto the entries we publish 
(B>on an experimental basis. In order to keep things as simple as possible, 
(B>what we$BCW(Be done is simply use the atom  element. We$BCS(Be using rel=$BGM(B 
(B>ink$BG
(Bto indicate that this is just a random link of unknown purpose or 
(B>intent. However, atom requires that a link element have a mime-type. Given 
(B>that we have no idea what the mime-type for the URI is, what mime-type 
(B>should we use?
(B
(BAre you talking about the type attribute (as Sam and others have
(Bpointed out, that's no longer required) or the rel attribute.
(BThe text seems to indicate the former, the examples the later.
(B
(BPlease clarify.
(B
(BRegards,Martin.
(B
(B
(B
(B>Some examples of links that we$BCW(Be published in the last few minutes follow:
(B>
(B>href="http://news.bbc.co.uk/go/click/rss/0.91/public/-/1/hi/world/middle_east/4286129.st"/>
(B>http://www.nytimes.com/2005/02/22/politics/22memo.html"/>
(B>href="http://www.washingtonpost.com/wp-dyn/articles/A43009-2005Feb22.html"/>
(B>href="http://www.nytimes.com/2005/02/22/books/22thompson.html"/>
(B>http://imdb.com/name/nm0588766/"/>
(B>href="http://www.denverpost.com/Stories/0,1413,36~78~2723673,00.html"/>
(B>
(B>For an example feed that contains entries that link to the New York Times, see:
(B>http://atom.pubsub.com/32/6c/1bc36c085cdc9ecd23efa73a.xml
(B>
(B>Is there a better $BES(Bel$BG
(Bvalue then $BEM(Bink$BG (B What mime-type should we be 
(B>using? Is there a better way to accomplish what we$BCS(Be doing?
(B>
(B>Your comments would be appreciated. If we$BCW(Be done something completely 
(B>insane here, please be gentle.
(B>
(B> bob wyman
(B>

Re: AtomPubIssuesList for 2005/02/22

[Martin Duerst]

At 01:44 05/02/23, Paul Hoffman wrote:
>This list should still be focused on the format draft. As our document 
editors toil away diligently, we can still offer editorial suggestions. 
This is also a reasonable time to start creating format extensions  and 
talking about them here.

Hello Paul,
Will there be a two-week WG last call for the Atom format
document, as usual with IETF WGs?
Regards,Martin. 

Re: AtomPubIssuesList for 2005/02/22

[Ezra Cooper]

I've just posted PaceSliceAndDice. This describes a way for clients and
servers to break large collections into small pieces.

The basic ideas here are not new to the group, but the language is more
precise and I've thrown in a mechanism that helps to compose
"subcollections" with "time-interval queries." I'm assuming that we'll use
the same syntax to collect entries, templates, "resources", etc.

In this proposal, none of the item-specific data is included in the
collection document (you have to dereference the individual URLs), but we
should probably address that in an independent proposal.

Suggestions on how to make this more clear are heartily welcomed. Also,
there are lots of details that could be changed without damaging the
proposal, so I'll be interested in your criticisms.

It should now be safe to close these, which I originally authored:
PaceDateRangeCollections
PaceRangesAndSubsets
PaceReturnCollNewestToOldest
PaceServerCollectionSubsets

Thanks,
Ezra
 


On 2/22/05 10:52 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Ezra Cooper wrote:
>> 
>> I don't object to these being closed, but I'd like to have the chance to
>> make a new proposal which would be an alternative to PaceEntryQuery.
>> 
>> My proposal will:
>> 
>>   * provide for collections, obeying the "slash semantics"
>>   * allow for date-range queries over any (top-level) collection or
>> sub-collection
>>   * not provide for index-based ranges, or other kinds of searches.
>> 
>> If I can have this done by the end of the day, could we discuss it in this
>> round?
> 
> Yes.
> 
> - Sam Ruby
> 

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Bill de hÓra]

Paul Hoffman wrote:
At 12:25 PM + 2/20/05, Bill de hÓra wrote:
Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally 
significant in terms of how Atom layers onto the Web and is best taken 
forward under feed state,

- Feed state discussion ought to deal explicitly with entry state, as 
that's the more difficult case.

My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want the 
model to be different, and most don't care about the differences between 
those two.

When the next draft of the document comes out, this can be rehashed 
again in the WG if there is a single specific Pace that gives a complete 
delta from that draft.

However, that Pace will not necessarily hold up us going to IETF last 
call, unless our AD wants it to. This kind of "does the model say A or 
B" discussion is quite appropriate in IETF last call, where folks who 
have very different model ideas might join in.
Ok, my opinions above stand, irrespective of when you think the 
discussion should be scheduled; there's an architectural issue wrt how 
Atom layers Web representations and there are tradeoffs to be 
considered. Anyway, I thought we were done with Paces.

cheers
Bill

Re:

[Eric Scheid]

On 23/2/05 6:31 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:

> However, atom requires that a link element have a mime-type. Given that we
> have no idea what the mime-type for the URI is, what mime-type should we use?

@type is optional.

Link elements MAY have a type attribute, whose value
MUST conform to the syntax of a MIME  media type [RFC2045].



e.

Re:

[Sam Ruby]

Bob Wyman wrote:
However, atom requires that a link element have a mime-type. Given that we
have no idea what the mime-type for the URI is, what mime-type should we
use?
It type attributes are optional in the current draft.
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt
4.6.3  The "type" Attribute
   Link elements MAY have a type attribute, whose value MUST conform to
   the syntax of a MIME media type [RFC2045].
This was changed in Format-03 as a result of the following:
   http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults
(Note: there is a typo in abstract, should be "make the TYPE attribute 
optional)

- Sam Ruby

atom-syntax@mail.imc.org

[Bob Wyman]

At PubSub, we allow users to subscribe to RSS/Atom entries
that contain user-specified URIs. (Using a query like: URI:nytimes.com) Users
of this feature have often asked us to augment the entries we publish by
attaching the URIs we discover to the entries. The idea has been to make it
easier for people to build applications that exploit these links and to avoid
forcing clients to parse the full source entries.

 

So, we’ve started adding these “links to URIs”
to the entries we publish on an experimental basis. In order to keep things as
simple as possible, what we’ve done is simply use the atom 
element. We’re using rel=”link” to indicate that this is just
a random link of unknown purpose or intent. However, atom requires that a link
element have a mime-type. Given that we have no idea what the mime-type for the
URI is, what mime-type should we use?

 

Some examples of links that we’ve published in the
last few minutes follow:

 













 

For an example feed that contains entries that link to the
New York Times, see:

http://atom.pubsub.com/32/6c/1bc36c085cdc9ecd23efa73a.xml

 

Is there a better “rel” value then “link”?
What mime-type should we be using? Is there a better way to accomplish what we’re
doing?

 

Your comments would be appreciated. If we’ve done
something completely insane here, please be gentle.

 

    bob
wyman

 

Re: AtomPubIssuesList for 2005/02/22

[Sam Ruby]

Ezra Cooper wrote:
I don't object to these being closed, but I'd like to have the chance to
make a new proposal which would be an alternative to PaceEntryQuery.
My proposal will:
  * provide for collections, obeying the "slash semantics"
  * allow for date-range queries over any (top-level) collection or
sub-collection
  * not provide for index-based ranges, or other kinds of searches.
If I can have this done by the end of the day, could we discuss it in this
round?
Yes.
- Sam Ruby

Re: AtomPubIssuesList for 2005/02/22

[Ezra Cooper]

On 2/22/05 7:31 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> 
> As Tim noted[1], the collection paces appear to be in a bit of a
> disarray.  His suggestion that the authors address this over the past
> few days did not achieve the desired result.  Given this, I am going to
> tentatively declare all the collection paces which contain TBDs, XXXs,
> and questions in square brackets as abandoned and therefore recommended
> for closure.

Sorry that I've been moving slowly on this. Just been a bit busy the past
week.
 
> So, currently under discussion:
> 
>PaceCollectionIdiom
>PaceCollectionSyntax
>PaceEntryQuery
> 
> And, recommended for closure:
> 
>PaceDateRangeCollections
>PaceRangesAndSubsets
>PaceReturnCollNewestToOldest
>PaceServerCollectionSubsets

I don't object to these being closed, but I'd like to have the chance to
make a new proposal which would be an alternative to PaceEntryQuery.

My proposal will:

  * provide for collections, obeying the "slash semantics"
  * allow for date-range queries over any (top-level) collection or
sub-collection
  * not provide for index-based ranges, or other kinds of searches.

If I can have this done by the end of the day, could we discuss it in this
round?

Ezra

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Paul Hoffman]

At 12:25 PM + 2/20/05, Bill de hÓra wrote:
Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally 
significant in terms of how Atom layers onto the Web and is best 
taken forward under feed state,

- Feed state discussion ought to deal explicitly with entry state, 
as that's the more difficult case.
My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want 
the model to be different, and most don't care about the differences 
between those two.

When the next draft of the document comes out, this can be rehashed 
again in the WG if there is a single specific Pace that gives a 
complete delta from that draft.

However, that Pace will not necessarily hold up us going to IETF last 
call, unless our AD wants it to. This kind of "does the model say A 
or B" discussion is quite appropriate in IETF last call, where folks 
who have very different model ideas might join in.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: AtomPubIssuesList for 2005/02/22

[Paul Hoffman]

At 10:31 AM -0500 2/22/05, Sam Ruby wrote:
So, currently under discussion:
  PaceCollectionIdiom
  PaceCollectionSyntax
  PaceEntryQuery
And, recommended for closure:
  PaceDateRangeCollections
  PaceRangesAndSubsets
  PaceReturnCollNewestToOldest
  PaceServerCollectionSubsets
Right. Because these Paces are all protocol-related, the discussion 
of them should be be on the atom-protocol mailing list. (See 
 if you need tracking/subscribing 
information.)

This list should still be focused on the format draft. As our 
document editors toil away diligently, we can still offer editorial 
suggestions. This is also a reasonable time to start creating format 
extensions  and talking about them here.

--Paul Hoffman, Director
--Internet Mail Consortium

AtomPubIssuesList for 2005/02/22

[Sam Ruby]

As Tim noted[1], the collection paces appear to be in a bit of a 
disarray.  His suggestion that the authors address this over the past 
few days did not achieve the desired result.  Given this, I am going to 
tentatively declare all the collection paces which contain TBDs, XXXs, 
and questions in square brackets as abandoned and therefore recommended 
for closure.

So, currently under discussion:
  PaceCollectionIdiom
  PaceCollectionSyntax
  PaceEntryQuery
And, recommended for closure:
  PaceDateRangeCollections
  PaceRangesAndSubsets
  PaceReturnCollNewestToOldest
  PaceServerCollectionSubsets
- Sam Ruby
[1] http://www.imc.org/atom-syntax/mail-archive/msg13651.html