Subject: Work Queue rotation #2

From: Tim Bray <[email-masked]>
Date: Tue, 06 Jul 2004 10:24:45 -0700

Per the current state of our issues list 
(http://www.intertwingly.net/wiki/pie/AtomPubIssuesList) we're supposed 
to be striving for consensus on PaceIntrospection and PaceEntryOrigin.

The discussion has been fairly light in volume and rather poorly 
focused, but on behalf Paul and myself, here's our best take on where 
we are:

1. PaceEntryOrigin.  There appears to be rough consensus that this 
back-pointer is a good idea.  Discussion of its exact syntax has been 
sucked into the PaceLinkConstruct rat-hole.  So, let's go ahead and 
wire it into the next set of drafts consistent with the way they are 
(which I take it means another <link rel=""> value) and, if we decide 
to change course on the way we do links, we'll change it then along 
with all the other links.

2. PaceIntrospection.  We don't detect consensus of any kind, rough or 
smooth, which means that there's nothing we can ask the editors to do.  
I'm not sure whether it's a problem with the way the Pace is written, 
or the focus of the discussion, or what, but let's declare temporary 
defeat on this one.  I think most of us think that having a documented 
introspection discover/introspection mechanism is an important piece of 
the puzzle, it's just that we haven't got a proposal written down yet 
that we can build consensus around.  Everyone please feel free to 
revise/recast/re-propose something in this area and we'll try again 
later.

So, Sam will now turn the crank and bring forward another small set of 
issues for us to try to knock off the list.   We need to work on at 
least one issue that affects the protocol, not just the data-format, 
drafts.  Also, given that we'd like to get a set of drafts done in time 
for the August IETF, it would be nice to select a few things that we 
have a chance of knocking off in the next week or two.

  -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 06 Jul 2004 19:09:31 +0100

Tim Bray wrote:

> 1. PaceEntryOrigin.  [...]

> (which I 
> take it means another <link rel=""> value) and, if we decide to change 
> course on the way we do links, we'll change it then along with all the 
> other links.

FTR: <link> was added as option. I'm not seeing consensus on that 
option and personally don't think it should be used over a full 
element *this* round, but I'm happy the editors have enough 
information to make a call one way or another.

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Tue, 6 Jul 2004 12:54:49 -0600

> information to make a call one way or another.
I'd recommend putting this in <link> for now, since that's consistent 
with how we are currently pointing to everything outside of the feed 
(...unless I'm forgetting something).  I'm not suggesting this as a way 
to build inertia for keeping it there (though that's where I expect to 
end up preferring it), but because we're going to need to discuss the 
general topic of pulling things out of <link> and putting them into 
their own elements anyway, so why not start of from one consistent 
model, and then discuss other possible consistent models.

Ultimately, wherever it goes now, unless we dump <link> entirely, where 
to put this URI is going to have to be discussed again. So it doesn't 
matter THAT much.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 07 Jul 2004 11:14:00 +0200

Thanks Tim, your take on each seems altogether reasonable.

I wonder if it might be worth adding a "try it" option to the list of 
possible actions - the next release of the spec will presumably have 
versioning protection, so ideas for which there is no obvious consensus 
could be inserted with a caveat that they were exploratory. If features 
appear to work ok in practice (and people actually use them) then 
there's a good case for them staying in. If there is little (positive) 
feedback, the feature gets dropped.

Cheers,
Danny.

Tim Bray wrote:

> (http://www.intertwingly.net/wiki/pie/AtomPubIssuesList) we're 
> supposed to be striving for consensus on PaceIntrospection and 
> PaceEntryOrigin.
>
> smooth, which means that there's nothing we can ask the editors to 
> do.  I'm not sure whether it's a problem with the way the Pace is 
> written, or the focus of the discussion, or what, but let's declare 
> temporary defeat on this one.  I think most of us think that having a 
> documented introspection discover/introspection mechanism is an 
> important piece of the puzzle, it's just that we haven't got a 
> proposal written down yet that we can build consensus around.  
> Everyone please feel free to revise/recast/re-propose something in 
> this area and we'll try again later.
>
> drafts.  Also, given that we'd like to get a set of drafts done in 
> time for the August IETF, it would be nice to select a few things that 
> we have a chance of knocking off in the next week or two.
>
>  -Tim
>
>

-- 

Raw
http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 07 Jul 2004 18:41:14 +0200

On Tue, 6 Jul 2004 12:54:49 -0600, Antone Roundy <[email-masked]>  
wrote:

> (...unless I'm forgetting something).

I agree. Let's just keep the link construct discussion out for now.  
Whenever we reach any consensus on how link constructs should look like,  
all current <link>s will adopt that.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 07 Jul 2004 19:05:20 +0200

On Tue, 06 Jul 2004 10:24:45 -0700, Tim Bray <[email-masked]> wrote:

> 1. PaceEntryOrigin. [...] So, let's go ahead and wire it into the
> next set of drafts consistent with the way they are (which I take it
> means another <link rel=""> value) and, if we decide to change

Sounds good.

> 2. PaceIntrospection. [...] let's declare temporary defeat on this one.

I agree. We need more, or better, proposals for this one. Mr. MacLeod and  
myself are doing some research into whether WebDAV might be used return  
DAV properties as a «site map» that allows for introspection for both the  
API side of things, but also for other, maybe not Atom-related, stuff.

---

From: Kevin Marks <[email-masked]>
Date: Wed, 7 Jul 2004 11:30:07 -0700

> with all the other links.

The goal of this element is to make the sources of a composite  feed
clearer. However, just a source URl is nto really sufficient for this,
as the other semantic elements of a feed can be affected too.

There is an alternative here, which was discussed briefly at the end
of the atom community meeting and mentioned here before. This is to
expand and clarify the feed/entry inheritance model such that an entry
can declare the feed-level elements for its original feed.

PaceItemCopyright declares this for the copyright element. The current
0.3 draft just has a note saying [[explain inheritence]] under
atom:author etc.

feed explicitly defines:
title, link, author, contributor,tagline,id, generator, copyright,
info, modified  (and entry)
entry defines:
title, link, author, contributor, id, modified, issued, created,
summary, content

There is a general notion of inheritance of attributes, which is made
explicit for copyright, author and contributor. However this is
problematic for the ones with the same names in feed and entry, but
semantic differences:
title, link, id
and the feed level ones not present in entry:
tagline, generator, copyright (fixed by PaceItemCopyright)

PaceEntryOrigin is a workaround for the semantic collision on link,
but the problem remains with title.

So, how about giving these different names, so that the inheritance
model can remain and be simplified:

Replace feed-level title,link and id with feedtitle, feedlink and feedid.

That way the entry can explicitly over-ride the feedtitle, feedlink
and feedid when it is a composite feed, in the same way as they do
with author, contributor, copyright etc.
Clients then have the explicit semantic information they need to
decide how to display such things.

Otherwise, we're going t keep coming up with these exception cases to
work around this.

I realise that proposing renaming the top-level elements this way is
disruptive, but better to disrupt now than later. If the wise heads
here can see a better way of expressing this semantic distinction
clearly, speak up.

---

From: Jens Alfke <[email-masked]>
Date: Wed, 7 Jul 2004 12:50:25 -0700

> can declare the feed-level elements for its original feed.

Why not represent each of the components of a composite feed as 
separate <feed> elements?

Either allow multiple top-level <feed> elements in the XML document, or 
allow a <feed> element to contain another <feed> element as a child, to 
indicate grouping.

This has the advantage over Kevin's suggestion that the feed-level data 
won't have to be repeated in every entry: this saves space and parsing 
time, and eliminates potential ambiguities like the possibility of 
multiple entries with conflicting metadata for the same feed.

(Apologies if this has been suggested before; I'm new here. By way of 
introduction, I work on Safari RSS.)

_______________________________________
Jens Alfke — Atom/RSS Wrangler — Apple Computer
he took a duck in the face at 250 knots

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 7 Jul 2004 18:35:38 -0400

Jens Alfke wrote:
>Why not represent each of the components of a composite feed as separate
<feed> elements?
	This has been proposed before, however, the general consensus seems
to be that we should avoid this solution since it may lead to the creation
of "feeds-of-feeds" -- something which we would all like to avoid. 
	The fear is that if a feed can contain feeds, then we'll rapidly see
"feed-of-feed-of-feed-of-feed...". i.e. Atom feeds will start looking like
OPML files... The intent of atom is not to provide for arbitrarily deep
nesting of data but rather to model simple, one-level deep collections of
entries.
	Of course, as you suggest, supporting "feed-of-feeds" would have the
nice attribute that "feed-level data won't have to be repeated in every
entry." However, I think the consensus is that potentially increased size of
entries is a valid trade-off to avoid the problems and complexities that
come from supporting nested feeds. Also, there is some anecdotal data that
indicates that at least in some composite feed applications (such as
PubSub.com's), the normal case is for an aggregate feed to be dominated by
entries that wouldn't be able to share meta-data with other entries in the
same aggregate feed. (i.e. in a single aggregate feed, you might have 30 or
50 entries, but each of them was extracted from a different source feed.)
	The solution we've been using is one of the ones that was discussed
at the end of the Atom Community Meeting... We insert a <ps:source-feed>
element that contains an extract of the feed-level metadata for each item we
pack into the aggregate feeds. For an example, look at the feed below:
(Note: I am aware that this is *not* a valid Atom feed for a number of
reasons. This is *not* part of our released system.)

http://atom.pubsub.com/c3/cd/7a625435c020f57b2536e64cc6.xml

		bob wyman

---

From: Ken MacLeod <[email-masked]>
Date: 07 Jul 2004 21:35:37 -0500

"Bob Wyman" <[email-masked]> writes:

> 	This has been proposed before, however, the general consensus
> seems to be that we should avoid this solution since it may lead to
> the creation of "feeds-of-feeds" -- something which we would all
> like to avoid.

I have another possible solution.

This solution is based on breaking the strong association of a "feed"
to its site, section, or category.  By breaking this association, the
"feed" can be used solely for the protocol aspect, and the
relationship of entries to sites, authors, categories, sections, and
contributors can be made explicit, and then easily and explicitly
replicated.

    http://intertwingly.net/wiki/pie/FeedVsSite

This is what a current "feed" looks like:

    <?xml version="1.0" encoding="UTF-8"?>
    <feed xmlns="http://example.com/newformat#">
      <title>Kitty Adventures.</title>
      <id>tag:example.com,2004:kitties</id>
      <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
      <author>
        <name>Kitty Owner</name>
      </author>
      <modified>2003-06-07T09:30:00+02:00</modified>

      <entry>
        <title>Russian Blue</title>
        <id>tag:example.com,2004:kitties/russian-blue</id>
        <link rel="alternate" type="text/html" href="http://example.com/kitties/russian-blue.html"/>
        <issued>2003-06-07T09:30:00+02:00</issued>
        <modified>2003-06-07T09:30:00+02:00</modified>
        <content src="http://example.com/kitties/russian-blue.jpg">
      </entry>
    </feed>

Here is a "protocol instance" of a "feed" with its information
refactored to be separate from the physical feed:

    <?xml version="1.0" encoding="UTF-8"?>
    <feed xmlns="http://example.com/newformat#">
      <modified>2003-06-07T09:30:00+02:00</modified>

      <site>
        <title>Kitty Adventures.</title>
        <id>tag:example.com,2004:kitties</id>
        <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
        <author ref="tag:example.com,2004:authors/kitty"/>
      </site>

      <author>
        <id>tag:example.com,2004:authors/kitty</id>
        <name>Kitty Owner</name>
      </author>

      <entry>
        <title>Russian Blue</title>
        <id>tag:example.com,2004:kitties/russian-blue</id>
        <origin ref="tag:example.com,2004:kitties"/>
        <link rel="alternate" type="text/html" href="http://example.com/kitties/russian-blue.html"/>
        <issued>2003-06-07T09:30:00+02:00</issued>
        <modified>2003-06-07T09:30:00+02:00</modified>
        <author ref="tag:example.com,2004:authors/kitty"/>
        <content src="http://example.com/kitties/russian-blue.jpg">
      </entry>
    </feed>

This has the following features:

 * The entry does not *inherit* information, it explicitly refers to
   its origin <site> and explicitly refers to its <author>, even if it
   is the same author as the site.

 * The referenced constructs (aka entities, resources) can be copied
   whole to new feeds.

 * The link type, @ref, of the reference makes this "deep copy"
   linking explicit for that purpose (processing and recursion can be
   specified).

 * The concept of "site" (or "section" or "category") is more concrete
   than "feed".

This differs from, or expands on, earlier "include by reference"
proposals by dissociating the "logical information" of what we call a
"feed" and puts it more precisely its own entity construct ("site").
By doing so, it also enables the entry to be explicit about things
like authors and contributors, without "inheriting" from a feed.

This also scales well when "physical feeds" are used as indexes, when
sites, sections, or categories can have multiple physical feeds
(minimal, full), and for entries that "exist" in multiple categories
or sections to indicate both their origin category/section *and* site.

More examples to follow in the wiki page.  Note, this is not yet a
proposal (Pace), just exploration and discussion.

  -- Ken

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 8 Jul 2004 11:09:31 -0400

Ken MacLeod proposes:
Creating <site/> and </author> elements which are peers to entries and are
referenced by the entries rather than inherited by them.
	Does this mean that a composite feed that contained entries from 30
different sites, written by 30 different authors, would have 30 <site/>
elements and 30 <author/> elements at the feed level which would then be
linked to the corresponding entries using URN's (the tags)?
	I think the RDF-folk would like this idea. It takes us away from
monolithic chunks of XML and moves us towards lots of little pieces that are
linked together in semantic networks... Of course, the RDF-folk would not be
happy with the syntax you propose.
	Ideas, and specifications, have a habit of evolving and morphing...
I can see in your proposal a number of fairly obvious and potentially
inevitable evolutions. My gut feel tells me that the URN's will evolve into
URI's, so that they can be used like URLs, and then into IRIs. The idea will
be that you shouldn't be forced to include the <site/> element in the feed
itself. People will want to be able to save bytes by making these things
resources that can be referenced externally from the feed itself. Then, when
we have <site/> objects on the web, we'll see arguments for expanding the
number and variety of elements that are in <site/> "documents." The "Site
Description Language" will be born and will provide for all sorts of
interesting data -- including links to WSDL files (i.e. UDDI like stuff),
etc. Site Description Documents will serve as "super DNS entries" that
eventually grow into the "Rich Site Description Language." A similar
evolution would occur with <author/> elements -- the "Rich Author
Description Language" isn't far away but would eventually be replaced by the
"Rich Person Description Language." In that case, we would have all sorts of
debates about alignment with FOAF and various bibliographic standards for
the description of authors and their relationships to organizations, other
authors, etc.
	While the scheme, after some evolution, would allow for some really
wonderful semantic analysis opportunities, it would increase the complexity
of handling feeds -- when parsing feeds, you would have to build separate
buffers for <site/>, <author/> and <entry/> elements so that you could
correlate them when necessary. If URI's are used and thus external
references were allowed, you'd have to build a cache of these elements in
order to reduce the network traffic involved in correlating them to entries
at processing time. That, of course, would introduce all the problems which
are related to currency of data. We'd need to introduce a "time-to-live"
element or attribute to ensure that people didn't rely on too-old instances
of the site or author data. A few other cache-control flags and attributes
would also serve us well...
	But, perhaps I exaggerate. It's an interesting proposal, but I think
one that would have to be very, very carefully considered before moving
forward.

		bob wyman