Re: sub feeds (was Re: Call for final Paces for consideration: deadline imminent)

2005-02-03 Thread Eric Scheid

On 3/2/05 7:18 PM, Robert Sayre [EMAIL PROTECTED] wrote:

 This is better.  I guess I just hadn't grok'd the idea of using
 entries to reference feeds, but now that I see the angle brackets I
 get it.
 
 Yes, feeds are entries.

no, feeds are collections, entries describe resources, and while feeds are
also resources that only means that entries can describe feeds, not actually
be feeds.

e. 



Re: PaceCollection

2005-02-03 Thread =?ISO-8859-1?Q?Bill_de_h=D3ra?=
James Snell wrote:
In any case, we're talking about something as simple as the name of a
single element.  I just don't see any real technical value in changing
it's name.  It doesn't make processing any easier.  It doesn't change
any of the functional semantics.  It doesn't address any critical bugs
in the design.  It just doesn't do anything.
I don't think asking or looking for technical value is that relevant 
here. Names are important [witness the arguments over the name RSS]. 
In markup, element naming tends to matter.

In this case replacing atom:feed with atom:collection doesn't help me 
personally understand the format better - I'm 0 on PaceCollection.

cheers
Bill


Re: tagline - subtitle

2005-02-03 Thread Martin Duerst
At 02:59 05/02/03, Danny Ayers wrote:

+1.

Subtitle is less obscure, and as Graham suggests could reasonably
encompass tagline. Summary isn't far away, but subtitle and tagline
are both more suggestive of the kind of half-a-sentence people use in
this position, rather than a paragraph+.
+1 from me, too. I think subtitle is also easier to get for
non-English speakers than 'tagline'.
Regards,Martin. 



Re: PaceEntriesElement

2005-02-03 Thread =?ISO-8859-1?Q?Bill_de_h=D3ra?=
Robert Sayre wrote:
 1. XML containment relates feed and entry metadata to the data being 
described, thereby defining a consistent model for future extension 
elements;
I'm dubious about this claim. XML containment has even less semantic 
grist to it than UML aggregation. My sense is when we get down to it, 
we'll end up defining explicitly what containment means and there will 
be multiple meanings.


 2. Multiple feeds can be aggregated and presented using a single data 
format without having to modify the entries within those feeds to 
incorporate their original feed metadata;
That sounds like a win.

 3. Digital signatures can be safely applied to feeds and entries 
without needing special-case exceptions on how to recreate the signature 
after aggregation;
Ultimately I'll defer to an expert on this, but I'd like to see an 
example of a special case that is circumvented ;)


 6. Practically zero changes for format05 feeds in the simple case. 
Entry elements are wrapped with atom:entries instead of headers being 
wrapped with atom:head.
Why not make make atom:head an atom:entry?

 7. Differentiates elements lower in a hierarchy (collection members) 
from metadata.
See my comment on 1. I think it only differentiates when we say it does, 
and this already suggests two containment 'semantics' (ie, there'll be 
an if/else in the code). Btw, this sounds like it's going to work like 
RDF/XML striping.

cheers
Bill


Re: Thinking ahead: Atom Extension Proposals on the Wiki?

2005-02-03 Thread Danny Ayers

On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
 
 James Snell wrote:
 I'm just thinking ahead a bit on this, but I am wondering if it would
 be possible for those of us interested in proposing non-core
 extensions to Atom to use the Wiki as the forum for sharing proposals
 for extensions once the core syntax has been finalized?

 Go4it.

Yep, good idea. I can see a few in the intray: ipaddress/host (for
anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension
is in the process of being revised, and an Atom-compatible syntax is
planned; Yahoo's media object extension.

A Wiki template would be nice - have you started writing anything up yet, James?

Cheers,
Danny.



-- 

http://dannyayers.com



Re: PaceMustBeWellFormed

2005-02-03 Thread Julian Reschke
Bill de hÓra wrote:
If,
 - 6.2 was dropped and probably
 - the first sentence of the Pace was dropped,
 - the rest of the 1st para was dropped down into 6.1
 - there was some weasel wording about RFC3023 compliance
how would you feel about the rest of it?
...
I think the main issue here is first we say
1) ...SHOULD use application/atom+xml...
...then, if you don't want to...
2) ...SHOULD use application/xml...
...then finally...
3) otherwise MAY use text/xml.
That is a problem in itself. Either we mandate a specific content type 
or we don't (I think we should). If we mandate one, we should say that 
behaviour of documents served with a different type is simply undefined.

Note that most of the nasty RFC3023 problems only apply to text/*, in 
particular I don't see why we would want to RECOMMEND to use a charset 
parameter on application/* content types.

Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


PaceCommentFeeds posted

2005-02-03 Thread Antone Roundy
This doesn't seem to have made it when I sent it last night, so here it 
is again:

An alternative to PaceEntriesElement - doesn't address all of the same 
issues, but combined with PaceAggregationDocument, would address a 
number of them.

http://www.intertwingly.net/wiki/pie/PaceCommentFeeds
Abstract
Enable the creation of comment feeds (comments on an entry from another 
feed) and the atomization of other hierarchical data, such as 
discussion forums, without recursion, by adding comments to the 
lin/@rel registry, and allowing atom:content and atom:summary as 
children of atom:head.
Status

Open
Rationale
* Comments on weblog entries and comment feeds are a reality today. 
Atom does not currently have a good way to support them.
* Other hierarchical data that is sometimes syndicated could use a 
good method of representation using Atom.
* This method enables this while preserving the simplicity of a 
flat feed model.

Proposal
In section 4.2 of draft-ietf-atompub-format-05.txt, add the following 
to the lists of child elements of atom:head:

   atomSummary?
   atomContent?
and:
  atom:head elements MUST NOT contain more than one atom:summary 
element.
  atom:head elements MUST NOT contain more than one atom:content 
element.

Add the following to section 4.6.2:
  The value comments signifies that the URI in the value of the 
href attribute identifies a resource containing comments on the content 
of the containing atom:feed or atom:entry element. For example, the URI 
may identify another Atom feed document whose entries are comments 
about the containing atom:entry.



Re: Thinking ahead: Atom Extension Proposals on the Wiki?

2005-02-03 Thread James Snell

I will start working on the template this week and will get something
posted by the weekend.


On Thu, 3 Feb 2005 11:46:14 +0100, Danny Ayers [EMAIL PROTECTED] wrote:
 On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
 
  James Snell wrote:
  I'm just thinking ahead a bit on this, but I am wondering if it would
  be possible for those of us interested in proposing non-core
  extensions to Atom to use the Wiki as the forum for sharing proposals
  for extensions once the core syntax has been finalized?
 
  Go4it.
 
 Yep, good idea. I can see a few in the intray: ipaddress/host (for
 anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension
 is in the process of being revised, and an Atom-compatible syntax is
 planned; Yahoo's media object extension.
 
 A Wiki template would be nice - have you started writing anything up yet, 
 James?
 
 Cheers,
 Danny.
 
 
 --
 
 http://dannyayers.com
 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: PaceCollection

2005-02-03 Thread Antone Roundy
On Wednesday, February 2, 2005, at 11:55  PM, James Snell wrote:
In any case, we're talking about something as simple as the name of a
single element.  I just don't see any real technical value in changing
it's name.  It doesn't make processing any easier.  It doesn't change
any of the functional semantics.  It doesn't address any critical bugs
in the design.  It just doesn't do anything.
Allow me to exaggerate.  Had we been using the following names, there 
would obviously be a point in changing them:

guacamole
chonmage
blueberryThis is my blog/blueberry
raspberry2004-01-25T10:04:00+/raspberry
chonmage
mountain
blueberryJohhny learns to read/blueberry
raspberry2004-01-25T10:04:00+/raspberry
[...]
/mountain
mountain
blueberryI resolve to blog/blueberry
raspberry2004-01-24T14:02:00+/raspberry
[...]
/mountain
/guacamole
Is collection more descriptive than feed of what we're using it 
for?  Would it make for quicker absorbtion of the concept by people not 
already familiar with the term feed?  Would it confuse those already 
familiar with the term feed?

My only objection to collection is that it has two more syllables 
than feed.



Re: PaceCollection

2005-02-03 Thread James Snell

On Thu, 3 Feb 2005 09:12:04 -0700, Antone Roundy [EMAIL PROTECTED] wrote:
 
 On Wednesday, February 2, 2005, at 11:55  PM, James Snell wrote:
  In any case, we're talking about something as simple as the name of a
  single element.  I just don't see any real technical value in changing
  it's name.  It doesn't make processing any easier.  It doesn't change
  any of the functional semantics.  It doesn't address any critical bugs
  in the design.  It just doesn't do anything.
 
 Allow me to exaggerate.  Had we been using the following names, there
 would obviously be a point in changing them:
 

You wouldn't need to change them if guacamole had a well-known,
well-understood meaning in relation to what the XML syntax was trying
to accomplish. The term feed has a well-known, well-understood
meaning.

 guacamole
 chonmage
 blueberryThis is my blog/blueberry
 raspberry2004-01-25T10:04:00+/raspberry
 chonmage
 mountain
 blueberryJohhny learns to read/blueberry
 raspberry2004-01-25T10:04:00+/raspberry
 [...]
 /mountain
 mountain
 blueberryI resolve to blog/blueberry
 raspberry2004-01-24T14:02:00+/raspberry
 [...]
 /mountain
 /guacamole
 
 Is collection more descriptive than feed of what we're using it
 for?  Would it make for quicker absorbtion of the concept by people not
 already familiar with the term feed?  Would it confuse those already
 familiar with the term feed?
 

I say yes to all of these.

 My only objection to collection is that it has two more syllables
 than feed.
 
 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: PaceEntriesElement

2005-02-03 Thread Robert Sayre
Bill de hÓra wrote:

 2. Multiple feeds can be aggregated and presented using a single data 
format without having to modify the entries within those feeds to 
incorporate their original feed metadata;

That sounds like a win.

 3. Digital signatures can be safely applied to feeds and entries 
without needing special-case exceptions on how to recreate the 
signature after aggregation;

Ultimately I'll defer to an expert on this, but I'd like to see an 
example of a special case that is circumvented ;)

I'm not an expert, but I have produced signed feeds. It's easy to write 
what's known as a collectable signature, which allows its parent 
element to appear anywhere in the document.


 6. Practically zero changes for format05 feeds in the simple case. 
Entry elements are wrapped with atom:entries instead of headers being 
wrapped with atom:head.

Why not make make atom:head an atom:entry?
It does. It still groups the headers. It's just implicit.

 7. Differentiates elements lower in a hierarchy (collection members) 
from metadata.

See my comment on 1. I think it only differentiates when we say it does, 
and this already suggests two containment 'semantics' (ie, there'll be 
an if/else in the code). Btw, this sounds like it's going to work like 
RDF/XML striping.
Yes, I wrote the initial feed in the RDF validator.
Robert Sayre


Re: tagline - subtitle

2005-02-03 Thread Norman Walsh
/ Graham [EMAIL PROTECTED] was heard to say:
| Any chance of renaming atom:tagline to atom:subtitle? The two sample
| feeds posted today have the taglines ongoing fragmented essay by Tim
| Bray and WebDAV related news. Aren't taglines meant to be funny or
| catchy or clever?

+1

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | Old age is the most unexpected of all
http://nwalsh.com/| the things that happen to a man.--
  | Trotsky


pgpeWHzKC4gXm.pgp
Description: PGP signature


Re: RELAX-NG bug in draft-05?

2005-02-03 Thread Norman Walsh
/ David Powell [EMAIL PROTECTED] was heard to say:
| The RELAX-NG in draft-05 seems to allow atom:feed to contain
| anyElement - this doesn't seem to be allowed by the spec's prose - is
| this a typo?

More like a thinko. I probably just assumed that anyElement could
appear in atom:feed. I'm surprised the spec forbids it, but I'll
adjust the schema to reflect that if it's the consensus of the group.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | Man's great misfortune is that he has
http://nwalsh.com/| no organ, no kind of eyelid or brake,
  | to mask or block a thought, or all
  | thought, when he wants to.--Paul Valry


pgpaFM1Y9BUm2.pgp
Description: PGP signature


PaceRemoveVersionAttr

2005-02-03 Thread Norman Walsh
Some thoughts

- It seems very likely to me that Atom will evolve over time.

- For some applications, changing the namespace name with every
  version is entirely impractical. Atom may or may not be in this
  category. Do feeds become legacy? Are people storing entries with
  the expectation that the readers of 2014 will be able to display
  them, albeit perhaps imperfectly? Changing the namespace makes that
  *hard*. XSLT transformations and XML Queries for Namespace1 flatly
  will not work with Namespace2.

- When I look at a feed, I am comforted on some emotional level by my
  ability to know what version the creator intended it to be.

- Perhaps YAGNI applies.

I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | Life is a great bundle of little
http://nwalsh.com/| things.--Oliver Wendell Holmes


pgpKPxnFV8GN3.pgp
Description: PGP signature


Re: PaceRemoveVersionAttr

2005-02-03 Thread Graham
On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote:
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Yes. I like it too.
Graham


smime.p7s
Description: S/MIME cryptographic signature


RELAX NG Grammar question

2005-02-03 Thread Norman Walsh
There are some constraints that the RELAX NG grammar can't practically
enforce. Should it enforce the MUSTs of the specification or the SHOULDs?
For example, should it allow non-XHTML elements inside a Content
Construct with the type 'XHTML'?

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | If you are losing your leisure, look
http://nwalsh.com/| out! You may be losing your
  | soul.--Logan Pearsall Smith


pgprmgdM2J65G.pgp
Description: PGP signature


Re: PaceRemoveVersionAttr

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 02:18  PM, Norman Walsh wrote:
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
  version is entirely impractical. Atom may or may not be in this
  category. Do feeds become legacy? Are people storing entries with
  the expectation that the readers of 2014 will be able to display
  them, albeit perhaps imperfectly? Changing the namespace makes that
  *hard*. XSLT transformations and XML Queries for Namespace1 flatly
  will not work with Namespace2.
- When I look at a feed, I am comforted on some emotional level by my
  ability to know what version the creator intended it to be.
I used to be fairly attached to being able to see a version number in 
the feed, but no longer am, IF the following conditions are met.  In 
the following, b  a and X != Y--the rest is indeterminate:

1) A valid Atom X.a feed is guaranteed to be a valid Atom X.b feed
2) An application aware of Atom X.a can safely ignore changes made in 
Atom X.b

3) The namespace for Atom version X.a is guaranteed to be the same as 
for Atom version X.b

4) The namespace for Atom version X.a is guaranteed to be different 
than the namespace for Atom version Y.c

5) X can easily be determined by viewing the namespace for Atom version 
X.*

I think this is what we're aiming for, but I'm not certain that we have 
approved spec text to ensure it.  PaceExtendingAtom addresses some of 
this, but not all of it.  Do we need something more?



Re: Exactly one atom:contributor?

2005-02-03 Thread Robert Sayre
Norman Walsh wrote:
I find the constraint that an atom:feed or atom:entry can contain at
most one atom:contributor a little odd. Suppose Tom, Dick, and Harry
work on an entry, why can only two of them get credit (one as author
and one as contributor). Why am I not allowed to indicate that they
each contributed to the entry?
For that matter, I wonder if the constraint makes sense for author.
Kind of, sort of, maybe.
That's a typo on my part. The Relax NG is correct.
Robert Sayre


Re: PaceLinkEnclosure needs help

2005-02-03 Thread Ray Slakinski
I think your right in a way -- I agree that for 'alternate' it should 
be a child element, but I hate to do that for attachment so lets drop 
that I said that. Having said that I still think rel would be good to 
keep.

I want to keep it simple and as close to enclosure as possible.
[-]
Ray Slakinski
Fingerprint: C8AD 4847 2DA8 3469 079D  13F9 135D F0CF 1CFC FD03
Blog: http://ddll.sdf1.net
Mosher's Law of Software Engineering:
Don't worry if it doesn't work right.  If everything did, you'd
 be out of a job.
On 2-Feb-05, at 11:15 AM, Antone Roundy wrote:
On Wednesday, February 2, 2005, at 05:09  AM, Ray Slakinski wrote:
url, type, and length is pretty obvious, but rel could be used to 
specify alternate, torrent, quality and things like that, and allow 
future expansion without breaking when we do.

If the content being pointed to is an alternate of the entry content, 
link rel=alternate ... / is probably better--using attachment) 
for that would duplicate functionality.

@rel probably isn't the best name for the other values you suggest.  
Off the top of my head, I'd recommend allowing extension child 
elements or extension attributes to specify such things.




atom:content in atom:entry

2005-02-03 Thread Norman Walsh
Section 4.15 says:

4.15  The atom:content Element

   The atom:content element either contains or links to the content of
   the entry.  atom:entry elements MUST contain zero or one atom:content
   elements.

The constraint atom:entry elements MUST contain zero or one atom:content
elements. belongs in 4.3, I think.

And is it still true? I can't tell if I'm allowed to have more than one
if they have different types. What's the status quo?

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | Everything we love, no doubt, will pass
http://nwalsh.com/| away, perhaps tomorrow, perhaps a
  | thousand years hence. Neither it nor
  | our love for it is any the less
  | valuable for that reason.--John Passmore


pgp35KpcVXM3C.pgp
Description: PGP signature


Re: atom:content in atom:entry

2005-02-03 Thread Robert Sayre
Norman Walsh wrote:
Section 4.15 says:
4.15  The atom:content Element
   The atom:content element either contains or links to the content of
   the entry.  atom:entry elements MUST contain zero or one atom:content
   elements.
The constraint atom:entry elements MUST contain zero or one atom:content
elements. belongs in 4.3, I think.
And is it still true? I can't tell if I'm allowed to have more than one
if they have different types. What's the status quo?
The status quo is that you cannot, it's still true, and the requirement 
is in the wrong place.

The reason is that each atom:content element would require accessible 
alternative content, and result in reinvention of the feed structure. 
Also, no one uses them in Atom 0.3. Take a look at PaceEntriesElement as 
an alternative.

Robert Sayre


Updated Atom grammar

2005-02-03 Thread Norman Walsh
The test cases didn't turn out to be all that useful for my purpose,
so I turned instead to another careful reading of the spec. Here is an
updated grammar for Atom draft 0.5 modulo the constraint on
contributor which is apparently a spec error rather than a grammar
error :-)

The changes are:

* Fixed the namespace and version attribute
* Allow anyElement in atom:person
* Do not allow anyElement in atom:feed
* Fixed the Schematron test for author in entry to reflect atom:head
* Added Schematron rule to test for atom:content or atom:[EMAIL PROTECTED]
* Added Schematron rule to test for atom:summary or non-empty atom:content
* Constrain atom:content to appearing at most once.



atom.rnc
Description: Binary data

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | 'Heartless Cynics,' the young men
http://nwalsh.com/| shout, / Blind to the world of Fact
  | without; / 'Silly Dreamers,' the old
  | men grin / Deaf to the world of Purpose
  | within.--W. H. Auden


pgpIqpaKdaDXb.pgp
Description: PGP signature


Re: Exactly one atom:contributor?

2005-02-03 Thread Tim Bray

On Feb 3, 2005, at 2:03 PM, Norman Walsh wrote:
I find the constraint that an atom:feed or atom:entry can contain at
most one atom:contributor a little odd. Suppose Tom, Dick, and Harry
work on an entry, why can only two of them get credit (one as author
and one as contributor). Why am I not allowed to indicate that they
each contributed to the entry?
I'm pretty sure that's a bug.  -Tim


Re: RELAX NG Grammar question

2005-02-03 Thread Norman Walsh
/ Tim Bray [EMAIL PROTECTED] was heard to say:
| On Feb 3, 2005, at 1:50 PM, Norman Walsh wrote:
|
| There are some constraints that the RELAX NG grammar can't practically
| enforce. Should it enforce the MUSTs of the specification or the SHOULDs?
| For example, should it allow non-XHTML elements inside a Content
| Construct with the type 'XHTML'?
|
| Ideally we'd like two versions, or maybe some Schematron trickery so
| we get told about SHOULDs but it doesn't actually fail?

Ok, I'll plan to spend some more time thinking about the Schematron
expressions (and writing some of the hairier ones) after the spec is
really bolted down.

| As for the XHTML thing, I think this is going to happen all the time (foreign
| markup in embedded XHTML) and I don't think we should try to get in the way.
| However, I just now tried to think of some spec language to express this and
| came up empty. -Tim

I think the spec language is fine

   If the value of type is XHTML, the content of the Text construct
   MAY contain child elements.  The content SHOULD be XHTML text and
   markup that could validly appear directly within an xhtml:div
   element.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | Old age is the most unexpected of all
http://nwalsh.com/| the things that happen to a man.--
  | Trotsky


pgpc0wRIQVzgP.pgp
Description: PGP signature


Re: PaceRemoveVersionAttr

2005-02-03 Thread Sam Ruby
Norman Walsh wrote:
Some thoughts
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
  version is entirely impractical. Atom may or may not be in this
  category. Do feeds become legacy? Are people storing entries with
  the expectation that the readers of 2014 will be able to display
  them, albeit perhaps imperfectly? Changing the namespace makes that
  *hard*. XSLT transformations and XML Queries for Namespace1 flatly
  will not work with Namespace2.
- When I look at a feed, I am comforted on some emotional level by my
  ability to know what version the creator intended it to be.
For me, I'd like the comfort of knowing that a V1.0 feed will continue 
to be valid with respect to future versions of the specifications, and 
that tools written to consume V1.0 feeds will continue to work with 
subsequent versions of the specification.

RSS 0.9x (including 2.0) is evidence that the former is possible (I can 
cite some minor incompatibilities, but these are merely exceptions that 
prove the rule).  I do believe that the latter is also possible.

Without ever changing the namespace.
- Sam Ruby


Re: PaceRemoveVersionAttr

2005-02-03 Thread Sam Ruby
Antone Roundy wrote:
On Thursday, February 3, 2005, at 02:18  PM, Norman Walsh wrote:
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
  version is entirely impractical. Atom may or may not be in this
  category. Do feeds become legacy? Are people storing entries with
  the expectation that the readers of 2014 will be able to display
  them, albeit perhaps imperfectly? Changing the namespace makes that
  *hard*. XSLT transformations and XML Queries for Namespace1 flatly
  will not work with Namespace2.
- When I look at a feed, I am comforted on some emotional level by my
  ability to know what version the creator intended it to be.
I used to be fairly attached to being able to see a version number in 
the feed, but no longer am, IF the following conditions are met.  In the 
following, b  a and X != Y--the rest is indeterminate:

1) A valid Atom X.a feed is guaranteed to be a valid Atom X.b feed
2) An application aware of Atom X.a can safely ignore changes made in 
Atom X.b

3) The namespace for Atom version X.a is guaranteed to be the same as 
for Atom version X.b

4) The namespace for Atom version X.a is guaranteed to be different than 
the namespace for Atom version Y.c

5) X can easily be determined by viewing the namespace for Atom version X.*
I think this is what we're aiming for, but I'm not certain that we have 
approved spec text to ensure it.  PaceExtendingAtom addresses some of 
this, but not all of it.  Do we need something more?
That is what I am aiming for.
I put some placeholder text at the bottom of PaceRemoveVersionAttr, but 
it definately needs to be expanded/improved.

- Sam Ruby



Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread Tim Bray
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote:
1.) A web forum, where one post serves as the root of a collection of
other posts.
HTML--
http://groups-beta.google.com/group/bloggerDev/
Atom 0.3, root posts only--
http://groups-beta.google.com/group/bloggerDev/feed/topics.xml
Atom 0.3, all messages--
http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml
Q: Has any previous flavor of RSS had a solution for this?
Potential solutions that occur to me:
1. Ignore the problem
2. PaceEntriesElement could handle this
3. PaceFeedRecursive could handle this
4. PaceAtomHeadInEntry could handle this
5. PaceAggregationDocument could handle this
I honestly can't say which I prefer.  Would anyone like to try to put  
together examples of the solution in #2 through #5 so that we can  
consider the alternatives?

2.) A Blog w/ comments, where on post serves as the root of a  
collection
of other posts.

HTML--
http://www.livejournal.com/users/giant_moose/
Atom 0.3, no indication of comments--
http://www.livejournal.com/users/giant_moose/data/atom
Q: Has any previous flavor of RSS had a solution for this?
Q: Do we have a proposal on something to handle this?
I believe there is a proposal for a link rel=comment which would do  
the job.

3.) A List Status feed, where the only updates consist of one
collection replacing another.
RSS2 --
http://rss.netflix.com/Top100RSS
background info--
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd 
-4cba-959a-2bba6ae917f0
Q: Has any previous flavor of RSS had a solution for this?
Q: Do we have a proposal for something to handle this?
Dare points out that the feed suffers from lack of guids and dates,  
something that Atom would force them to fix, which would give an  
aggregator a better chance of doing something useful.  -Tim



On organization and abstraction

2005-02-03 Thread Tim Bray
On reflection, I am growing very negative on almost all of the 
Organization Paces, including FeedRecursive, PaceEntriesElement, 
PaceCollection.  Here's why: they represent to increase the level of 
abstraction in Atom, and in my experience, when the goal is 
interoperability across the network, abstraction hurts.  I would like 
it if the markup found in Atom documents was as close as possible to a 
typical human mental model.  The word feed has entered the 
vocabulary, even the non-geek vocabulary, and the notion that there are 
things (entries, stories, items, whatever) in feeds likewise.  Any 
attempt to abstract away and generalize along the lines of well, a 
feed is really an entry or well, an entry is really a feed or 
really, they're all just web resources and collections is dangerously 
close to verging on Architecture Astronautics.

Put another way, Adam Bosworth, likely one of the best computer 
programmers in the world, said every time I add abstraction to an 
interface I lose 90% of the audience.  I would like Atom to be more 
like Visual Basic and less like Lisp.

Put another way, starting in 1986 there was a system called SGML, an 
ISO standard for marking up documents, which was awesome in its 
generality; the notion of what a delimiter was, what a character was, 
what an element was, all these things were entirely abstract.   So, it 
was almost impossible to implement and never really caught on.

On the other hand, the notion that sometimes you have collections of 
feeds is easy to understand, easy to verbalize, and widely evidenced in 
practice (cf PubSub  friends), if not perhaps widely seen outside of 
geekland.  So I think I'm +1 on PaceAggregationDocument.  (And I think 
if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)

 -Tim


Re: Call for final Paces for consideration: deadline imminent

2005-02-03 Thread Tim Bray
On Feb 2, 2005, at 5:46 PM, Paul Hoffman wrote:
...
On Monday, Feb. 7, the Working Group's final queue rotation will 
consist of all Paces open at that time. Any Paces that have obvious 
holes in them (to be filled in later, more needs to go here, etc.) 
will be ignored. We have had over a year of time here, and many weeks 
since the previous attempt to close things out. On Monday, Feb. 14, we 
will assess WG consensus and ask the document authors to put together 
a final draft.
...
In case it's not obvious, I am 100% with Paul on this.  I think that 
the Atom format as it stands now is very close to a huge 80/20 point, 
and the world needs it.  Also, I think that one or two of the last 
outstanding Paces will result in a noticeable positive delta.

It's like when you get towards the end of a software project.  The 
engineers always know that they could make it better in just another 
few weeks' work, and at some point you have to let go and turn it over 
to the world.

Let's get our last round of Paces nicely nailed down and cleaned up and 
polished and ready to take up officially on Monday. -Tim



Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
Tim Bray wrote:
On reflection, I am growing very negative on almost all of the 
Organization Paces, including FeedRecursive, PaceEntriesElement, 
PaceCollection.  Here's why: they represent to increase the level of 
abstraction in Atom, and in my experience, when the goal is 
interoperability across the network, abstraction hurts. 
There's a diff of your feed in PaceEntriesElement. It's pushing it to 
claim one is more interoperable than the other. You just asked for 
examples 15 minutes ago, why don't you wait for them?

The word feed has entered the vocabulary, 
even the non-geek vocabulary, and the notion that there are things 
(entries, stories, items, whatever) in feeds likewise.  
None of the feed formats out there use the term feed in their 
vocabularies.

Any attempt to 
abstract away and generalize along the lines of well, a feed is really 
an entry or well, an entry is really a feed or really, they're all 
just web resources and collections is dangerously close to verging on 
Architecture Astronautics.
OK, define Feed and Entry. We haven't done it yet.
I think calling other designs astronautics is unjustified. HeadInEntry 
is astronautics in the worst way--just nest them. But hey that's just my 
opinion. Also, atom:content is architecture astronautics. Base64? 
Please. HTML in atom:copyright? architecture astronautics.

Put another way, Adam Bosworth, likely one of the best computer 
programmers in the world, said every time I add abstraction to an 
interface I lose 90% of the audience.  I would like Atom to be more 
like Visual Basic and less like Lisp.
This is not a meaningful comparison to me.
On the other hand, the notion that sometimes you have collections of 
feeds is easy to understand, easy to verbalize, and widely evidenced in 
practice (cf PubSub  friends), if not perhaps widely seen outside of 
geekland.  So I think I'm +1 on PaceAggregationDocument.  (And I think 
if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
I think you should wait for examples.
Robert Sayre


Re: Organization Use Cases

2005-02-03 Thread Robert Sayre
Tim Bray wrote:
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote:
1.) A web forum, where one post serves as the root of a collection of
other posts.
HTML--
http://groups-beta.google.com/group/bloggerDev/
Atom 0.3, root posts only--
http://groups-beta.google.com/group/bloggerDev/feed/topics.xml
Atom 0.3, all messages--
http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml

Q: Has any previous flavor of RSS had a solution for this?
By reference, there is wfw:commentrss. That's typing of items/entries by 
the type of link relation that points to them. That means you're going 
to have people calling things comments to get the interface to happen. 
It's nesting.

Potential solutions that occur to me:
1. Ignore the problem
2. PaceEntriesElement could handle this
3. PaceFeedRecursive could handle this
4. PaceAtomHeadInEntry could handle this
5. PaceAggregationDocument could handle this
I honestly can't say which I prefer.  Would anyone like to try to put  
together examples of the solution in #2 through #5 so that we can  
consider the alternatives?

I will put together examples for all of the alternatives, and I will add 
 one more example: planetsun.org.

2.) A Blog w/ comments, where on post serves as the root of a  collection
of other posts.
HTML--
http://www.livejournal.com/users/giant_moose/
Atom 0.3, no indication of comments--
http://www.livejournal.com/users/giant_moose/data/atom

Q: Has any previous flavor of RSS had a solution for this?
No, but the problem isn't that hard. I wouldn't be surprised if LJ has 
some private format for this, but I don't know if they do.

Q: Do we have a proposal on something to handle this?
PaceEntriesElement would do it.
I believe there is a proposal for a link rel=comment which would do  
the job.
It wouldn't handle that example. The comments are nested. XML elements 
nest pretty well. It would handle the first case... but only by 
reference. You couldn't subscribe to posts with comments.



3.) A List Status feed, where the only updates consist of one
collection replacing another.
RSS2 --
http://rss.netflix.com/Top100RSS
background info--
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd 
-4cba-959a-2bba6ae917f0

Q: Has any previous flavor of RSS had a solution for this?
Yes. http://npg.nature.com/pdf/newsfeeds.rdf, or there is OPML.
Q: Do we have a proposal for something to handle this?
Yes, any of the organization Paces would take care of this, other than 
the ordering problem, which no Pace addresses.

Dare points out that the feed suffers from lack of guids and dates,  
something that Atom would force them to fix, which would give an  
aggregator a better chance of doing something useful.  -Tim

Nesting collections would make the situation explicit.
Robert Sayre


CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread Bob Wyman








At PubSub.com, weve started
generating CAP over Atom files. By this I mean were
publishing using Atom files to encapsulate a stream of message which are
encoded using the CAP (Common Alerting Protocol) format. See: http://www.oasis-open.org/committees/download.php/6334/oasis-200402-cap-core-1.0.pdf
. 

Because CAP is an XML format, were
using atom:content elements with type=text/xml. In order to
ensure that there is something for aggregators to display if they dont
understand CAP, were generating atom:summary elements that contain a
textual summary of the CAP message which is in the atom:content. My hope is
that aggregator developers will commonly implement a pattern of displaying the atom:summary
rather then the atom:content in cases where they dont understand the XML
type of the content element.

I would appreciate any review
comments that you might be able to make on our use of Atom in this application.

For a sample Atom feed containing CAP messages which
describe recent earthquakes, please see:

http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml

 A
sample atom:entry extracted from this Atom Feed is below:



entry

ps:nodeID/pubsub/topics/301/ps:nodeID

title![CDATA[ Earthquake: M 1.6 (D) NORTHERN
CALIFORNIA 2005-02-04T02:00:43.100Z ]]/title

issued2005-02-03T21:04:42-05:00/issued

modified2005-02-03T21:04:42-05:00/modified

idtag:pubsub.com,2005:CAP:nc51156375/id

link rel='alternate' type='text/html'
href=''/

summaryAn earthquake occurred at
2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated
message and should not be considered authoritative.) /summary

content type='text/xml'

alert
xmlns=http://www.incident.com/cap/1.0

 identifiernc51156375/identifier


sender[EMAIL PROTECTED]/sender


sent2005-02-03T21:04:42-05:00/sent


statusTest/status


msgTypeAlert/msgType


scopePublic/scope


incidentsnc51156375/incidents

 info


categoryGeo/category


eventEarthquake/event


urgencyUnknown/urgency


severityUnknown/severity


certaintyUnknown/certainty


senderNamePubsub Earthquake Service/senderName

 headlineEarthquake:
M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z/headline


descriptionAn earthquake occurred at 2005-02-04T02:00:43.100Z. The
magnitude 1.6 event has been located in NORTHERN
 CALIFORNIA. (This is a computer-generated message and should not
be considered authoritative.) /description


webhttp://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm/web


parameterEventID=nc51156375/parameter


parameterVersion=1/parameter


parameterMagnitude=1.6 MD/parameter


parameterDepth=2 km/parameter


parameterVerified=N/parameter

 area


areaDesc2 km depth at latitude 38.8168, longitude -122.7915 at
location: NORTHERN CALIFORNIA/areaDesc


circle38.8168,-122.7915 0/circle

 /area

 /info

 /alert

/content

/entry



Note: I am aware of a few issues with our current use of
Atom:

1. We often issue
files that contain more than one entry with the same atom:id. For instance, you
might have a message which is followed in the file by an update concerning the
same incident or a Cancel message for the event. I
know this is a violation of the specification. We will eventually stop doing
this Please bear with us.

2. We currently
dont provide an atom:link element with rel=alternate when
we insert a CAP Cancel message into the feed. This is, of course,
because we have no page to point to for a deleted or cancelled event. In the
future, well consider having all such Cancel messages point to a common
static help page which explains a variety of reasons why a message may have
been deleted.

3. If you view
the Atom feed in a web browser, the result may not be terribly pleasing
Were still working on the style sheet.  Please pay attention only
to the source of the feed (i.e. do View Source).



This service compliments the Earthquake service that I recently
mentioned on this list. We will be publishing both raw Earthquake messages/feeds
as well as CAP messages/feed in the future. These two formats are targeted at
different audiences.



Your comments and/or suggestions would be appreciated.



 bob
wyman










Re: Organization Use Cases

2005-02-03 Thread Eric Scheid

On 4/2/05 1:54 PM, Robert Sayre [EMAIL PROTECTED] wrote:

 I believe there is a proposal for a link rel=comment which would do
 the job.
 
 It wouldn't handle that example. The comments are nested. XML elements
 nest pretty well. It would handle the first case... but only by
 reference. You couldn't subscribe to posts with comments.

I know of at least one blog where the comments are neither hierarchical nor
flat ... each comment can be in reply to multiple previous comments. How
would you model this in XML?

I would use

link rel=in-reply-to .../
link rel=in-reply-to .../
link rel=in-reply-to .../

and 

link rel=has-reply .../


(guessing at the @rel values)

e.



Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
Graham wrote:
On 4 Feb 2005, at 2:37 am, Tim Bray wrote:
On the other hand, the notion that sometimes you have collections of 
feeds is easy to understand, easy to verbalize, and widely evidenced 
in practice (cf PubSub  friends), if not perhaps widely seen outside 
of geekland.  So I think I'm +1 on PaceAggregationDocument.  (And I 
think if we adopted that we could certainly lose PaceHeadInEntry, 
right Bob?)

If you removed the ability to have entries within the feeds in 
aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally 
different task.
Why in the world should we define some other document format? OPML will 
do that just fine.

Robert Sayre


Re: PaceAggregationDocument (was: On organization and abstraction)

2005-02-03 Thread Eric Scheid

On 4/2/05 2:06 PM, Graham [EMAIL PROTECTED] wrote:

 If you removed the ability to have entries within the feeds in
 aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally
 different task.
 
 A collection of feeds would be something like a list of blogs about a
 certain topic? You get all the information you need in the feed-head,
 and supplying entries is fairly redundant. Essentially supplying recent
 entries from those feeds would be extra metadata about the feed.

I think the purpose of PaceAggregationDocument is to provide a means to
subscribe to an intermediary aggregator like pubsub, and thus receive
entries.

A collection of feeds for the purpose of a blog roll (ie. no entries) can be
modelled in atom as it currently stands - each entry is descriptive about
some resource, being a feed, and you'd just have a link rel=alternate / to
the feed itself.

e.



Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread Eric Scheid

On 4/2/05 1:15 PM, Tim Bray [EMAIL PROTECTED] wrote:

 3.) A List Status feed, where the only updates consist of one
 collection replacing another.
 
 RSS2 --
 http://rss.netflix.com/Top100RSS
 
 background info--
 http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd
 -4cba-959a-2bba6ae917f0
 
 Q: Has any previous flavor of RSS had a solution for this?
 Q: Do we have a proposal for something to handle this?
 
 Dare points out that the feed suffers from lack of guids and dates,
 something that Atom would force them to fix, which would give an
 aggregator a better chance of doing something useful.  -Tim

This is not too much unlike how Nature Publishing Group is providing RSS1.0
feeds of table of contents for each issue of their journals. They have one
feed URI for each issue, and a 304 redirect on the current issue feed URI.
Each article has a unique id. They also have an RSS feed where each item is
a link to each of their various journal titles. They could also quite
reasonably have a per-title feed where each item is a link to each issue's
feed.

e.



Re: On organization and abstraction

2005-02-03 Thread Tim Bray
On Feb 3, 2005, at 7:06 PM, Graham wrote:
On the other hand, the notion that sometimes you have collections of 
feeds is easy to understand, easy to verbalize, and widely evidenced 
in practice (cf PubSub  friends), if not perhaps widely seen outside 
of geekland.  So I think I'm +1 on PaceAggregationDocument.  (And I 
think if we adopted that we could certainly lose PaceHeadInEntry, 
right Bob?)
If you removed the ability to have entries within the feeds in 
aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally 
different task.
I'm claiming they do the same thing.  Instead of
feed
 headidf1/id/head
 entry
  headidf1/id/head
  ide1/id
  /entry
 entry
  headidf1/id/head
  ide2/id
  /entry
 entry
  headidf2/id/head
  ide3/id
  /entry
 /feed
you'd have
aggregation
 headidf1/id/head
 feedidf1/id
  entryide1/id/entry
  entryide2/id/entry
  /feed
 feedidf2/id
  entryide3/id/entry
  /feed
 /aggregation
Which on the face of it seems like an improvement. -Tim


Re: PaceEnclosuresAndPix status

2005-02-03 Thread Mark Nottingham
Just a point of data; most logos are designed to look good at a 1-to-1 
aspect ratio.

On Jan 24, 2005, at 5:25 PM, Tim Bray wrote:

On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote:
+1
Should there be a suggested size for images?
A suggested aspect ratio, actually.  Drat.  Brent Simmons loved this 
idea, and I meant to update the draft.  Would anyone be upset if I 
updated the draft to say an aspect ratio of 2 (horizontal) to 1 
(vertical)?  -Tim


--
Mark Nottingham http://www.mnot.net/


Re: Posted PaceEntryOrder (was Entry order)

2005-02-03 Thread Mark Nottingham
My preference would be something like
This specification assigns no significance to the order of atom:entry 
elements within an Atom Feed Document. Atom Processors MAY present 
entries in any order, unless a specific ordering is required by an 
extension.

(I.e., I could come up with the UseLexicalOrdering extension, and 
require processors to understand it to use the feed, assuming our 
extensibility model supports that, which I very much hope it will).

Seem reasonable?
On Feb 2, 2005, at 4:18 PM, David Powell wrote:
This specification assigns no significance to the order of
atom:entry elements within the feed. Processors MAY present entries in
a different order to which they are appear in an Atom Feed Document.
--
Mark Nottingham http://www.mnot.net/


RE: On organization and abstraction

2005-02-03 Thread Bob Wyman

Tim Bray wrote:
 So I think I'm +1 on PaceAggregationDocument.  (And I think 
 if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
-1...
PaceAggregationDocument does not seem to me to add much benefit for
all the costs that it entails. I'm particularly concerned that adding a new
type of root document aggregation is likely to add enough to the
complexity of Atom that only a subset of developers will actually get around
to supporting this third type of document -- a type which doesn't exist in
the simple RSS aggregators that exist today.
I see two non-compelling benefits to PaceAggregationDocument over
PaceHeadInEntry:
1. In the case where a feed will contain more than one entry from a
foreign feed, you only have to include the atom:head data once. Thus,
there would be some increase in efficiency of encoding... However, as I've
pointed out on numerous occasions, this is a rare case. Typically, at
PubSub, we DO NOT see many cases where atom:head information is repeated in
a single instance of a feed.
2. It is easier to see how one would sign an aggregated entry since
you don't muck with the contents of entry by inserting the HeadInEntry. This
problem, however, would be solved by canonicalization rules that said that
you should remove HeadInEntry before processing signatures, or, rules that
said that you had to insert HeadInEntry before signing anything, or filter
rules that allowed one to flag HeadInEntry as not part of the signed
content. (i.e. alternative solutions exist...)

But, there are tremendous problems with the proposal:
1. It looks like I can't intersperse native entries with
aggregated entries. This is a nuisance. I would like to see people insert
entries with HeadInEntry when they copy something from another feed into
their own feed. PaceAggregationDocument says that your feed must have either
native entries or foreign entries, but it can't have both. This seems
like an unnecessary constraint.
2. As mentioned before, the introduction of a new level of
abstraction (i.e. aggregation) is likely to scare off a good proportion of
the aggregator developers. Current aggregators don't have the concept of
aggregation in them. Thus, new design and new architecture will be
required to address this Pace. On the other hand, staying with HeadInEntry
is much more gentle on the existing systems and thus much more likely to be
useful in the field.
3. Since there will be at least some subset of aggregators that
won't understand the aggregation thing, it is likely that we'll have a
chicken and egg problem. No one will produce aggregation documents since
not everyone supports them. Thus, no one will support them since no one
generates them. On the other hand, HeadInEntry will slide past minimally
updated aggregators with no trouble -- i.e. folk who don't want to do the
work of handling the stuff properly will simply ignore the Head element...
(i.e. it would be suicide for producers like PubSub to support
PaceAggregationDocument.)
4. Massive changes need to be made to the specification when we
don't have a great deal of time left before we're supposed to be doing a
Last Call. This is dangerous.

-1. I really don't see any compelling benefit in exchange for the
tremendous risk and cost of accepting PaceAggregationDocument and dropping
HeadInEntry. Let's avoid adding to the levels of abstraction here and keep
it simple. We should have feeds and entries -- nothing else.

 I would like Atom to be more like Visual Basic and less like Lisp.
As an ex-Visual Basic Product Manager, I think this would be a good
idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to
reader: Visual Basic .NET is .NOT Visual Basic...

bob wyman


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Tim Bray
Sent: Thursday, February 03, 2005 9:38 PM
To: Atom Syntax
Subject: On organization and abstraction


On reflection, I am growing very negative on almost all of the 
Organization Paces, including FeedRecursive, PaceEntriesElement, 
PaceCollection.  Here's why: they represent to increase the level of 
abstraction in Atom, and in my experience, when the goal is 
interoperability across the network, abstraction hurts.  I would like 
it if the markup found in Atom documents was as close as possible to a 
typical human mental model.  The word feed has entered the 
vocabulary, even the non-geek vocabulary, and the notion that there are 
things (entries, stories, items, whatever) in feeds likewise.  Any 
attempt to abstract away and generalize along the lines of well, a 
feed is really an entry or well, an entry is really a feed or 
really, they're all just web resources and collections is dangerously 
close to verging on Architecture Astronautics.

Put another way, Adam Bosworth, likely one of the best computer 
programmers in the world, said every time 

Re: PaceRemoveVersionAttr

2005-02-03 Thread Mark Nottingham
In its present form, I want to get rid of the version attribute. That's 
not to say that I don't want something with more useful semantics, on a 
separate axis from the namespace.

So, +1 to the Pace.
On Feb 3, 2005, at 1:18 PM, Norman Walsh wrote:
Some thoughts
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
  version is entirely impractical. Atom may or may not be in this
  category. Do feeds become legacy? Are people storing entries with
  the expectation that the readers of 2014 will be able to display
  them, albeit perhaps imperfectly? Changing the namespace makes that
  *hard*. XSLT transformations and XML Queries for Namespace1 flatly
  will not work with Namespace2.
- When I look at a feed, I am comforted on some emotional level by my
  ability to know what version the creator intended it to be.
- Perhaps YAGNI applies.
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Be seeing you,
  norm
--
Norman Walsh [EMAIL PROTECTED] | Life is a great bundle of little
http://nwalsh.com/| things.--Oliver Wendell Holmes
--
Mark Nottingham http://www.mnot.net/



Re: PaceRemoveInfoAndHost

2005-02-03 Thread Mark Nottingham
+1
Welcome to the club :)
On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
Proposal
---
Remove atom:info and atom:host from The Atom Syndication Format.
Remove atom:host
---
No one seems to like the atom:host element. It doesn't do what its 
original proponents wanted and many of its detractors still oppose it. 
Design by committee at its worst.

Remove atom:info
---
Back when we were arguing about IETF vs. W3C, mnot said in the IETF, 
its easier to shut down a solo raving loony. In the threads on 
atom:info, it seems I am playing the role of solo raving loony. So, 
let's have the process take over.

Robert Sayre

--
Mark Nottingham http://www.mnot.net/



RE: Entry order

2005-02-03 Thread Bob Wyman

David Powell wrote:
 It looks like this might have got lost accidently when the 
 atom:head element was introduced. Previously Atom 0.3 said [1]:
 Ordering of the element children of atom:feed element MUST NOT be
 considered significant.
+1. 
The order of entries in an Atom feed should NOT be significant. This
is, I think, a very, very important point to make. 

bob wyman




RE: PaceAggregationDocument (was: On organization andabstraction)

2005-02-03 Thread Bob Wyman

Eric Scheid wrote:
 I think the purpose of PaceAggregationDocument is to provide a 
 means to subscribe to an intermediary aggregator like pubsub, and
 thus receive entries.
If that is the motivation, then I think you really should find some
other motivation. 
Frankly, it is exceptionally unlikely that we at PubSub could take
the risk of relying on aggregation documents since it is probable that it
will be quite some time before substantially all aggregators are updated to
support them. It is much more likely that a large proportion of existing and
new aggregators will rapidly upgrade their Atom 0.3 support to support the
Atom 1.0 feed and entry documents -- but not aggregation documents. 
My experience with past protocol upgrading events leads me to
believe that a large percentage of developers will tire once they have the
obvious and familiar bits supported and will then release what they claim to
be compliant code but with aggregation support delayed until next
release... At PubSub, we'll end up with customers complaining that the Atom
we're generating is not supported by their aggregators... Folk will accuse
us of having buggy code. Competitors will attack us for screwing our users
in some Quixotic quest for Atom Purity when we should be addressing user
needs by supporting RSS V2.0 and core Atom... No thank you. I really don't
want to go there. Find some other reason to push aggregation documents. But,
whatever you do, PLEASE don't drop HeadInEntry. If you do drop HeadInEntry,
we'll just have to keep using the ps: namespace to put it back in.
For us to support aggregation documents might be politically correct
-- if this Pace is accepted, however, it would be suicide from a business
point of view. Please don't ask us to do that which we can not do...

bob wyman




Re: Call for final Paces for consideration: deadline imminent

2005-02-03 Thread Mark Nottingham
Walter brings up an important point; has, or when will, the drafts be 
compared to the requirements in the charter?

Cheers,
On Feb 2, 2005, at 8:36 PM, Walter Underwood wrote:
The charter says that Atom will work for archiving. We don't know that
it will, and it hasn't been discussed for months.
Is the current Atom spec sufficient for archiving? If not, we aren't 
done.

wunder
--On February 2, 2005 5:46:51 PM -0800 Paul Hoffman [EMAIL PROTECTED] 
wrote:

Greetings again. And, thanks again for all the work people did on the 
last work queue rotation. We now have the end of the format draft 
squarely in sight.

The WG still has a bunch of finished Paces that have not been 
formally considered, a (thankfully) much smaller number of unfinished 
Paces, and a couple of promises that I'll write that up as a Pace 
soon. We need to finish soon in order to make our milestone, and I 
believe we can do so gracefully.

On Monday, Feb. 7, the Working Group's final queue rotation will 
consist of all Paces open at that time. Any Paces that have obvious 
holes in them (to be filled in later, more needs to go here, 
etc.) will be ignored. We have had over a year of time here, and many 
weeks since the previous attempt to close things out. On Monday, Feb. 
14, we will assess WG consensus and ask the document authors to put 
together a final draft.

Note that this is not the last opportunity for work on the Atom 
format. For one thing, there are plenty of non-core extensions that 
folks have been mulling over; having the core draft finally finished 
will help those to emerge. Further, we need to do the final work on 
the protocol document. Also, during the formal IETF Last Call, 
discussion of the format draft will be welcome from everyone 
(including people who have not read any of the earlier drafts).

Please do *not* rush out to write a Pace unless it is for something 
that is *truly* part of the Atom core, and you really believe that it 
is likely that there will be consensus within a week. If your idea is 
appropriate as an extension, or is for something that is quite 
similar to something else that has explicitly gotten lack of 
consensus, please do not write a Pace. In the former case, please 
hold your extensions for a few weeks; in the latter case, please 
recognize that asking the WG to
focus on something that they don't want will likely cause us to do a 
worse job at carefully reviewing things that we all want.
So, if you have an incomplete Pace now, you have a few more days to 
complete it. Of course, everyone should feel free to continue talking 
about the current Paces now, and to continue to suggest editorial 
changes to the current Internet Draft.

--Paul Hoffman, Director
--Internet Mail Consortium


--
Walter Underwood
Principal Architect, Verity

--
Mark Nottingham http://www.mnot.net/


Re: Organization Use Cases

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 07:54  PM, Robert Sayre wrote:
2.) A Blog w/ comments, where on post serves as the root of a  
collection
of other posts.

HTML--
http://www.livejournal.com/users/giant_moose/
Atom 0.3, no indication of comments--
http://www.livejournal.com/users/giant_moose/data/atom
Q: Has any previous flavor of RSS had a solution for this?
No, but the problem isn't that hard. I wouldn't be surprised if LJ has 
some private format for this, but I don't know if they do.

Q: Do we have a proposal on something to handle this?
PaceEntriesElement would do it.
I believe there is a proposal for a link rel=comment which would 
do  the job.
It wouldn't handle that example. The comments are nested. XML elements 
nest pretty well. It would handle the first case... but only by 
reference. You couldn't subscribe to posts with comments.

I don't see any reason why a feed reader couldn't give you the option 
of automatically subscribing to the comment feeds that grow off of the 
posts in a feed and automatically organize those subscriptions 
hierarchically under the original.  Then, if a thread got 
uninteresting, you could unsubscribe to just that part of it and never 
have to download that chunk of it again.  A slight variation would be 
to provide a one-click subscription to comments off of the top level, 
and then automatically subscribe to the threads underneath it--that 
would require a lot less manual maintenance to avoid overload.  If the 
top level were fully automatic, it would be pretty messy for a high 
volume site like Slashdot, for example, but a nested comments feed 
would be worse, since it would be less simple to hack off the 
uninteresting threads.



Re: Feed State [was: Work Queue Rotation #16]

2005-02-03 Thread Mark Nottingham
This is now PaceNoFeedState;
  http://www.intertwingly.net/wiki/pie/PaceNoFeedState
On Jan 31, 2005, at 3:46 PM, Mark Nottingham wrote:
x. Managing Feed State
Atom Processors MAY keep state (e.g., metadata in atom:head, entries) 
sourced from Atom Feed Documents and combine them with other Atom Feed 
Documents, in order to facilitate a contiguous view of the contents of 
the feed. The manner in which Atom Feed Documents are combined in 
order to reconstruct a feed (including methods of identifying 
duplicate entries, updating metadata, and dealing with missing 
entries) is out of the scope of this specification, but may be defined 
by an extension to Atom.

--
Mark Nottingham http://www.mnot.net/


Re: PaceFeedState status

2005-02-03 Thread Mark Nottingham
I'm OK with dropping wholefeed; I'll edit the pace to accommodate that.
WRT warning users; you realise that putting something in the user 
manual, README or box of the consumer (e.g., This product does not 
manage feed state.) would satisfy that requirement?

Would SHOULD make you feel better?
Cheers,
On Jan 24, 2005, at 5:09 PM, Joe Gregorio wrote:
I am +1 on the //atom:head/atom:[EMAIL PROTECTED]'prev'], but -1 on
//atom:head/atom:[EMAIL PROTECTED]'wholefeed'] and -1 on any of the verbage
that makes demands on clients, for example, Atom consumers MUST warn
users when they do not have the complete state of a feed 
   -joe
On Mon, 24 Jan 2005 16:17:42 -0800, Tim Bray [EMAIL PROTECTED] 
wrote:
If there were no further discussion: Like PaceSupersede, this model of
publishing does not (so far) enjoy consensus support.   -Tim


--
Joe Gregoriohttp://bitworking.org

--
Mark Nottingham http://www.mnot.net/


Re: On organization and abstraction

2005-02-03 Thread Mark Nottingham
+1 - someone else made a comment about OPML which really hit the spot; 
if you try to make a format do all things, it does most of them 
badly...

On Feb 3, 2005, at 6:37 PM, Tim Bray wrote:
On reflection, I am growing very negative on almost all of the 
Organization Paces, including FeedRecursive, PaceEntriesElement, 
PaceCollection.  Here's why: they represent to increase the level of 
abstraction in Atom, and in my experience, when the goal is 
interoperability across the network, abstraction hurts.  I would like 
it if the markup found in Atom documents was as close as possible to a 
typical human mental model.  The word feed has entered the 
vocabulary, even the non-geek vocabulary, and the notion that there 
are things (entries, stories, items, whatever) in feeds likewise.
--
Mark Nottingham http://www.mnot.net/


Re: CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread James Snell

This is excellent to see.  I'm glad to see that you were not afraid to
break the syntax rules to get things started. :-)  The format looks
good.

On Thu, 3 Feb 2005 21:50:51 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
  
  
 
 At PubSub.com, we've started generating CAP over Atom files. By this I
 mean we're publishing using Atom files to encapsulate a stream of message
 which are encoded using the CAP (Common Alerting Protocol) format. See:
 http://www.oasis-open.org/committees/download.php/6334/oasis-200402-cap-core-1.0.pdf
 . 
 
 Because CAP is an XML format, we're using atom:content elements with
 type=text/xml. In order to ensure that there is something for aggregators
 to display if they don't understand CAP, we're generating atom:summary
 elements that contain a textual summary of the CAP message which is in the
 atom:content. My hope is that aggregator developers will commonly implement
 a pattern of displaying the atom:summary rather then the atom:content in
 cases where they don't understand the XML type of the content element. 
 
 I would appreciate any review comments that you might be able to make on our
 use of Atom in this application. 
 
 For a sample Atom feed containing CAP messages which describe recent
 earthquakes, please see: 
 
 http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml 
 
 A sample atom:entry extracted from this Atom Feed is below: 
 
   
 
 entry 
 
 ps:nodeID/pubsub/topics/301/ps:nodeID 
 
 title![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA
 2005-02-04T02:00:43.100Z ]]/title 
 
 issued2005-02-03T21:04:42-05:00/issued 
 
 modified2005-02-03T21:04:42-05:00/modified 
 
 idtag:pubsub.com,2005:CAP:nc51156375/id 
 
 link rel='alternate' type='text/html'
 href='http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm'/ 
 
 summaryAn earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude
 1.6 event has been located in NORTHERN CALIFORNIA. (This is a
 computer-generated message and should not be considered authoritative.)
 /summary 
 
 content type='text/xml' 
 
 alert xmlns=http://www.incident.com/cap/1.0; 
 
   identifiernc51156375/identifier 
 
   sender[EMAIL PROTECTED]/sender 
 
   sent2005-02-03T21:04:42-05:00/sent 
 
   statusTest/status 
 
   msgTypeAlert/msgType 
 
   scopePublic/scope 
 
   incidentsnc51156375/incidents 
 
   info 
 
 categoryGeo/category 
 
 eventEarthquake/event 
 
 urgencyUnknown/urgency 
 
 severityUnknown/severity 
 
 certaintyUnknown/certainty 
 
 senderNamePubsub Earthquake Service/senderName 
 
 headlineEarthquake: M 1.6 (D) NORTHERN CALIFORNIA
 2005-02-04T02:00:43.100Z/headline 
 
 descriptionAn earthquake occurred at 2005-02-04T02:00:43.100Z. The
 magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a
 computer-generated message and should not be considered authoritative.)
 /description 
 

 webhttp://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm/web 
 
 parameterEventID=nc51156375/parameter 
 
 parameterVersion=1/parameter 
 
 parameterMagnitude=1.6 MD/parameter 
 
 parameterDepth=2 km/parameter 
 
 parameterVerified=N/parameter 
 
 area 
 
   areaDesc2 km depth at latitude 38.8168, longitude -122.7915 at
 location: NORTHERN CALIFORNIA/areaDesc 
 
   circle38.8168,-122.7915 0/circle 
 
 /area 
 
   /info 
 
 /alert 
 
 /content 
 
 /entry 
 
   
 
 Note: I am aware of a few issues with our current use of Atom: 
 
 1.   We often issue files that contain more than one entry with the same
 atom:id. For instance, you might have a message which is followed in the
 file by an update concerning the same incident or a Cancel message for
 the event. I know this is a violation of the specification. We will
 eventually stop doing this Please bear with us. 
 
 2.   We currently don't provide an atom:link element with
 rel=alternate when we insert a CAP Cancel message into the feed. This
 is, of course, because we have no page to point to for a deleted or
 cancelled event. In the future, we'll consider having all such Cancel
 messages point to a common static help page which explains a variety of
 reasons why a message may have been deleted. 
 
 3.   If you view the Atom feed in a web browser, the result may not be
 terribly pleasing We're still working on the style sheet.  Please pay
 attention only to the source of the feed (i.e. do View Source). 
 
   
 
 This service compliments the Earthquake service that I recently mentioned on
 this list. We will be publishing both raw Earthquake messages/feeds as well
 as CAP messages/feed in the future. These two formats are targeted at
 different audiences. 
 
   
 
 Your comments and/or suggestions would be appreciated. 
 
   
 
 bob wyman 
 
   


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: On organization and abstraction

2005-02-03 Thread James Snell

On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
 
 Tim Bray wrote:
  So I think I'm +1 on PaceAggregationDocument.  (And I think
  if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
 -1...
 PaceAggregationDocument does not seem to me to add much benefit for
 all the costs that it entails. I'm particularly concerned that adding a new
 type of root document aggregation is likely to add enough to the
 complexity of Atom that only a subset of developers will actually get around
 to supporting this third type of document -- a type which doesn't exist in
 the simple RSS aggregators that exist today.

+1 to this -1.  The aggregation element is not a necessary part of the
core and adds complexity without adding *significant* benefit to the
core.

 2. As mentioned before, the introduction of a new level of
 abstraction (i.e. aggregation) is likely to scare off a good proportion of
 the aggregator developers. Current aggregators don't have the concept of
 aggregation in them. Thus, new design and new architecture will be
 required to address this Pace. On the other hand, staying with HeadInEntry
 is much more gentle on the existing systems and thus much more likely to be
 useful in the field.

This is precisely why I don't think this belongs in the core.  For
those who need this type of functionality, the opportunity exists for
them to create a separate Internet-Draft that describes how to
aggregate feeds -- without adding complexity to the core syntax by
introducing elements that the vast majority of users will *likely*
never use.  (I obviously base this assumption on the reasoning that
most Atom users will use it as a drop in replacement for RSS).

 3. Since there will be at least some subset of aggregators that
 won't understand the aggregation thing, it is likely that we'll have a
 chicken and egg problem. No one will produce aggregation documents since
 not everyone supports them. Thus, no one will support them since no one
 generates them. 

Well, I wouldn't go this far.  There is obviously a requirement for it
for some folks and those folks are likely to make good use of it. 
What I would rather see the WG do is take a minimalist approach with
this.  Right now, I see aggregated feeds falling into that limited 20%
of use cases that could be done, but aren't necessarily critical to be
done.  Aggregation could be defined as an extension to Atom, and
later, based on an analysis of its implementation over time, can be
merged into the Atom core if deemed appropriate.  Merging it into the
core now does not guarantee that its adoption and use will be any
greater than if it were done as an extension.

 4. Massive changes need to be made to the specification when we
 don't have a great deal of time left before we're supposed to be doing a
 Last Call. This is dangerous.
 

+1. Big +1.  

 -1. I really don't see any compelling benefit in exchange for the
 tremendous risk and cost of accepting PaceAggregationDocument and dropping
 HeadInEntry. Let's avoid adding to the levels of abstraction here and keep
 it simple. We should have feeds and entries -- nothing else.
 

One point, HeadInEntry solves the problem of having a standalone Atom
Entry document be able to reference a feed of which it is a part. 
Unless I'm misreading something, if PaceAggregationDocument gets rid
of the ability to put Head elements in the entry, don't we lose this
capability?  (this is something that is important, for instance, in my
Atom Notification Protocol proposal)

  I would like Atom to be more like Visual Basic and less like Lisp.
 As an ex-Visual Basic Product Manager, I think this would be a good
 idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to
 reader: Visual Basic .NET is .NOT Visual Basic...
 

Aargh! VB... it burns!  (sorry, temporary flashback to past hell. 
Sorry Bob, VB was an excellent product, I just was forced to be
witness to some extremely bad uses of it.  Nightmares, I tell you,
nightmares!)

 bob wyman
 
 
-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: PaceRemoveInfoAndHost

2005-02-03 Thread James Snell

+1


On Thu, 3 Feb 2005 20:24:06 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
 
 +1
 
 Welcome to the club :)
 
 
 On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
 
 
  http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
 
  Proposal
  ---
  Remove atom:info and atom:host from The Atom Syndication Format.
 
  Remove atom:host
  ---
  No one seems to like the atom:host element. It doesn't do what its
  original proponents wanted and many of its detractors still oppose it.
  Design by committee at its worst.
 
  Remove atom:info
  ---
  Back when we were arguing about IETF vs. W3C, mnot said in the IETF,
  it's easier to shut down a solo raving loony. In the threads on
  atom:info, it seems I am playing the role of solo raving loony. So,
  let's have the process take over.
 
  Robert Sayre
 
 
 
 
 --
 Mark Nottingham http://www.mnot.net/
 
 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread James Snell

 Potential solutions that occur to me:
 
 1. Ignore the problem
 2. PaceEntriesElement could handle this
 3. PaceFeedRecursive could handle this
 4. PaceAtomHeadInEntry could handle this
 5. PaceAggregationDocument could handle this
 
 I honestly can't say which I prefer.  Would anyone like to try to put
 together examples of the solution in #2 through #5 so that we can
 consider the alternatives?
 

6. Handle the problem in a non-core extension.  

The core Atom syntax does not have to deal with all these cases as
long as it does not interfere with someones ability to deal with cases
later on. Get version one out the door.  Get folks to start
implementing it.  Start writing up extensions.  Get folks to implement
those extensions.  Figure out which extensions are Really Useful.  Add
those Really Useful Extensions to the core later.

-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
James Snell wrote:
On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
   4. Massive changes need to be made to the specification when we
don't have a great deal of time left before we're supposed to be doing a
Last Call. This is dangerous.
+1. Big +1.  

I really regret writing down the religion that format-05 seems to 
embody. Take a look at PaceEntriesElement. It does not propose a 
massive change. It's just *shorter*.

Some quotes from format-05:
Atom is an XML-based document format which describes lists of related 
information known as feeds. Feeds are  composed of a number of items, 
known as entries, each  with an extensible set of attached metadata. 
For example, each entry has a title.

The atom:feed element is the document (i.e., top-level)  element of 
an Atom Feed Document, acting as a container for  metadata and data 
associated with the feed

The atom:entry element represents an individual entry.
I really must find out more about this theology that allows one to 
divine the precise nature of lists, data, metadata, items, containers, 
and representations.

Robert Sayre


New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread James Snell

Figured I would formalize what I've been evangelizing the past couple of days.  

http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec

== Abstract ==

Defer the definition of solutions for aggregated feeds to a separate
Internet-Draft that is not a part of the Atom core syntax
specification.

== Status ==

Proposed (by [JamesSnell])

== Rationale ==

Aggregated feeds, while important, are currently not supported by the
existing RSS mechanisms and are relatively rare in comparison to their
single feed cousins.  Given the guidelines for proposals set forth in
this Wiki, this alone would justify moving the aggregation stuff off
to a separate document, at least for now.

* The 80/20 rule: If a feature will only be used by a small number of
people, and will create extra work and headaches for everyone else, it
probably doesn't belong in the core spec.
* Pick stuff that's already been proven to work and be interoperable,
and writing it down in a clean, clear way
* Keep it simple: The simplest thing that can possibly work tends to
be preferred over more complex solutions.

I absolutely acknowledge that there are a subset of folks for whom
aggregated feeds are very important.  But this is a subset.  Let that
subset document their ideas in a separate Internet-Draft; let them
implement those ideas and build momentum for them; then let us later
come back later and discuss the merits of merging those ideas into the
core.

== Proposal ==

(see abstract)

== Impacts ==

Defers PageAggregationDocument and PageFeedRecursive to a separate
Internet-Draft

* Lets Atom 1.0 get out the door faster.  
* Lets folks gain valuable implementation experience before committing
to major changes to the Atom core spec to support what is currently an
edge case
* Keeps the Atom core simple

== Notes ==


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: RELAX NG Grammar question

2005-02-03 Thread Henri Sivonen
On Feb 4, 2005, at 01:02, Norman Walsh wrote:
| As for the XHTML thing, I think this is going to happen all the time 
(foreign
| markup in embedded XHTML) and I don't think we should try to get in 
the way.
| However, I just now tried to think of some spec language to express 
this and
| came up empty. -Tim

I think the spec language is fine
   If the value of type is XHTML, the content of the Text construct
   MAY contain child elements.  The content SHOULD be XHTML text and
   markup that could validly appear directly within an xhtml:div
   element.
Depending on what W3C DTD you choose to read, you could put MathML or 
even SVG there, which is fine, IMO, because I don't think it makes 
sense to exclude well-known vocabularies that you could legitimately 
serve embedded in application/xhtml+xml.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 11:07  PM, James Snell wrote:
Figured I would formalize what I've been evangelizing the past couple 
of days.

http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec
The only reason why I'm not in favor of this (in fact, it occurred to 
me a little before I saw this message) is that leaving things as they 
are and deferring deciding how to handle aggregation would irreversibly 
enshrine HeadInEntry into the format, which all of the current 
organizational proposals are trying to replace.  Deciding to 
defer==deciding to do it HeadInEntry style.



Re: PaceExtendingAtom

2005-02-03 Thread Tim Bray

On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:
This specification describes Atom's XML markup vocabulary.  
Markup from
other vocabularies (foreign markup) can be used in Atom in 
a variety of
ways. Text Constructs may contain foreign markup which SHOULD 
be HTML or
XHTML.
What does this statement add? Why is HTML or XHTML normatively 
preferred over text, MathML, or any other vocabulary?
It's not preferred over text, you can say type='TEXT', but since this 
is a *text* construct and quite likely to be presented in rows  
columns (title, author, etc) simpler is better, so I'd think the SHOULD 
is sensible here. -Tim



Re: On organization and abstraction

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 09:08  PM, Bob Wyman wrote:
	I see two non-compelling benefits to PaceAggregationDocument over
PaceHeadInEntry:
	1. In the case where a feed will contain more than one entry from a
foreign feed, you only have to include the atom:head data once. Thus,
there would be some increase in efficiency of encoding... However, as 
I've
pointed out on numerous occasions, this is a rare case. Typically, at
PubSub, we DO NOT see many cases where atom:head information is 
repeated in
a single instance of a feed.
In the past few days, I've been reading people talking about different 
ways emerging for people to combine or divide the content of their own 
feeds based on what's going to end up in our category element and by 
other methods.  (See 
http://www.mezzoblue.com/archives/2005/02/03/information_/index.php).  
This kind of thinking could very well point the way to the emergence of 
more feeds being aggregated from a small number of sources.  Time will 
tell.

	2. It is easier to see how one would sign an aggregated entry since
you don't muck with the contents of entry by inserting the 
HeadInEntry. This
problem, however, would be solved by canonicalization rules that said 
that
you should remove HeadInEntry before processing signatures, or, rules 
that
said that you had to insert HeadInEntry before signing anything, or 
filter
rules that allowed one to flag HeadInEntry as not part of the signed
content. (i.e. alternative solutions exist...)
When you remove HeadInEntry, do you remove from the start of the head 
tag to the end of the /head tag, or do you also take out the newline 
after the /head tag...?  We'd have to be certain we defined the 
process precisely and that people followed it precisely.  The benefit 
of avoiding that complexity may be a little greater than it appears at 
first blush.

	But, there are tremendous problems with the proposal:
	1. It looks like I can't intersperse native entries with
aggregated entries. This is a nuisance. I would like to see people 
insert
entries with HeadInEntry when they copy something from another feed 
into
their own feed. PaceAggregationDocument says that your feed must have 
either
native entries or foreign entries, but it can't have both. This 
seems
like an unnecessary constraint.
You could always have a feed in the aggregation for the native 
entries.  But you do have a point--the thing that would be more 
difficult would be to occasionally import external content into a feed 
that is not always an aggregation--you'd either have to temporarily 
become an aggregation, refer to it rather than importing it, or forget 
it.  Out of curiosity though, how common is it to import entries 
wholesale from external sources as opposed to referring to them?

	2. As mentioned before, the introduction of a new level of
abstraction (i.e. aggregation) is likely to scare off a good 
proportion of
the aggregator developers. Current aggregators don't have the concept 
of
aggregation in them. Thus, new design and new architecture will be
required to address this Pace. On the other hand, staying with 
HeadInEntry
is much more gentle on the existing systems and thus much more likely 
to be
useful in the field.
Current aggregators don't have the concept of HeadInEntry either.  With 
HeadInEntry, it's easier because you don't have to deal with one more 
level of hierarchy--if you don't know about HeadInEntry and just ignore 
it, you can still function.  However, that leads to erroneously 
attributing an entry to the wrong feed.  To get it right, aggregators 
are going to have to understand SOMETHING new.  The containment in an 
aggregation document would be more intuitively obvious in meaning than 
seeing a head in an entry and figuring out that it was the head from 
the feed that used to surround the entry.

	4. Massive changes need to be made to the specification when we
don't have a great deal of time left before we're supposed to be doing 
a
Last Call. This is dangerous.
If we don't want to reorganize the spec to do this, we can create 
PaceAggregationDocument2 which does it more simply by making only four 
changes:

1) add an aggregation element
2) state that it requires an atom:head
3) state that it can contain any number of atom:feeds
4) state that it can be the document element


Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Eric Scheid

On 4/2/05 5:07 PM, James Snell [EMAIL PROTECTED] wrote:

 Defer the definition of solutions for aggregated feeds to a separate
 Internet-Draft that is not a part of the Atom core syntax
 specification.

+1



Re: CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread Eric Scheid


 Because CAP is an XML format, we're using atom:content elements with
 type=text/xml. In order to ensure that there is something for aggregators
 to display if they don't understand CAP, we're generating atom:summary
 elements that contain a textual summary of the CAP message which is in the
 atom:content. My hope is that aggregator developers will commonly implement
 a pattern of displaying the atom:summary rather then the atom:content in
 cases where they don't understand the XML type of the content element.

+1



Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Robert Sayre
Antone Roundy wrote:
leaving things as they are 
and deferring deciding how to handle aggregation would irreversibly 
enshrine HeadInEntry into the format, which all of the current 
organizational proposals are trying to replace.
That's right. Besides, HeadInEntry is trivial to do as an extension, so 
there's no reason to leave it in.

Robert Sayre


Re: Feed State [was: Work Queue Rotation #16]

2005-02-03 Thread Eric Scheid

On 4/2/05 4:03 PM, Mark Nottingham [EMAIL PROTECTED] wrote:

 This is now PaceNoFeedState;
  http://www.intertwingly.net/wiki/pie/PaceNoFeedState

+1

e.



Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread James Snell

On Fri, 04 Feb 2005 02:14:14 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
 
 Antone Roundy wrote:
 
  leaving things as they are
  and deferring deciding how to handle aggregation would irreversibly
  enshrine HeadInEntry into the format, which all of the current
  organizational proposals are trying to replace.
 
 That's right. Besides, HeadInEntry is trivial to do as an extension, so
 there's no reason to leave it in.
 

I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs.  That
mechanism does not have to be atom:head, but it does need to be part
of the core.

 Robert Sayre
 
 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]