date:20050203


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]

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


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

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: CAP over Atom (PubSub "Common Alerting Protocol" Earthquake Feeds...)



>> 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


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: On organization and abstraction

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  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  
tag to the end of the  tag, or do you also take out the newline 
after the  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: PaceExtendingAtom


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: New Pace: PaceAggregationInSeparateSpec

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: PaceProfile - new


I like the fundamental idea here, but there are a couple of issues:

1. There needs to be a clear description of what a profile is.  
2. There needs to be a clear description of how profiles are defined
3. There needs to be a clear description of how profiles are handled

The first is simple enough.

The second is a bit more difficult.  I would imagine the process would
be that a profile needs to be described by some form of document
(perhaps an Internet-Draft) but what process is required beyond that?
An IANA registry of profile identifiers?

The third deals with a very specific question: what should a client do
with a feed using a profile that it doesn't understand?

While this has the potential to cause a significant update to the
current document (something I'm hesitant to support), the current
@version is meaningless as is and really should be drastically
improved.  Something like the following would be far more useful.

...
...
...
...etc

Just for consideration, a possible alternative approach would be an
attribute that lists multiple profiles supported by a feed.  However,
this is obviously more complex and therefore less likely to be useful.

...

(p.s. the assumption in the above examples is that the values of the
@profile and @profiles attributes are meaningfully defined and
registered via IANA, like link @rel values)

On Thu, 3 Feb 2005 21:46:20 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote:
> 
> I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm.
> 
> [[[
> #pragma section-numbers off
> 
> == Abstract ==
> 
> Rearrange the format draft to allow @version (or a replacement
> attribute, @profile) to identify the kinds and cardinality of metadata
> that are required in the feed. Also, provide better separation between
> Atom-defined elements that are containers and Atom elements that are
> metadata.
> 
> == Status ==
> 
> New.
> 
> == Rationale ==
> 
> There are a number of use cases for Atom (e.g., blogs, news, archiving,
> stock quotes, systems monitoring); each has potentially different
> requirements for the presences of certain kinds of metadata. To cater
> to these use cases, and allow implementations to make assumptions about
> feed content when presenting it, we need to identify the *profile* of
> metadata that a feed can be expected to contain.
> 
> Furthermore, we need to ship at least one profile with the spec. Right
> now, it's embedded in the schema of what metadata elements are
> required; it would be better to explicitly call it out.
> 
> == Proposal ==
> 
> 1) Change the organisation of the document to this rough outline;
> 
> 1.   Introduction
>   1.1  Editorial Notes
>   1.2  Example
>   1.3  Conformance
>   1.4  Notational Conventions
> 
> 2.   Atom Documents
>   2.1 Atom Feed Documents
>   2.2 Atom Entry Documents
> 
> 3.   Atom Container Elements
>   3.1 The "atom:feed" Element
>   3.2 The "atom:head" Element
> 3.2.1 The "atom:profile" Attribute
>   3.3 The "atom:entry" Element
> 3.3.1 The "atom:profile" Attribute
> 
> 4.   Atom Core Metadata Elements
>   4.1  The "atom:title" Element
>   4.2  The "atom:id" Element
>   4.3  The "atom:link" Element
>   4.4  The "atom:updated" Element
>   4.5  The "atom:published" Element
>   4.6  The "atom:author" Element
>   4.7   The "atom:contributor" Element
>   4.8   The "atom:host" Element
>   4.9   The "atom:copyright" Element
>   4.10   The "atom:category" Element
>   4.11   The "atom:summary" Element
>   4.12   The "atom:content" Element
>   4.13   The "atom:introspection" Element
>   4.14   The "atom:post" Element
>   4.15   The "atom:edit" Element
>   4.16   The "atom:tagline" Element
>   4.17   The "atom:generator" Element
>   4.18   The "atom:info" Element
> 
> 5.   Common Atom Constructs
>   5.1  Text Constructs
>   3.2  Person Constructs
>   3.3  Date Constructs
>   3.4  Service Constructs
> 
> 6.   Atom Profiles
>   6.1 The Atom Syndication Profile
>   6.2 The Atom Archiving Profile
> 
> 7.   Managing Feed State
> 
> 8.   Securing Atom Documents
>   8.1  Digital Signatures
>   8.2  Encryption
> 
> 9.   Embedding Atom in Other Formats
> 
> 10.   Extending Atom
> 
> 11.   IANA Considerations
>   11.1  Registry of Link Relations
> 
> 12.  Security Considerations
> 
> This effectively positions Atom Documents as *containers* of bags of
> metadata, and the children of those containers as *metadata*; the only
> place where we constrain what kind of metadata is required in the feed,
> and how many times each one can appear, is in the profile definition
> (section 6 here).
> 
> This flexibility point allows new arrangements of metadata to be
> accommodated as new profiles, while still providing default profiles
> with the spec so that we ship something interoperable.
> 
> It also means that the only reason to

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/

New Pace: PaceAggregationInSeparateSpec


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: On organization and abstraction

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

PaceProfile - new

I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm.
[[[
#pragma section-numbers off
== Abstract ==
Rearrange the format draft to allow @version (or a replacement 
attribute, @profile) to identify the kinds and cardinality of metadata 
that are required in the feed. Also, provide better separation between 
Atom-defined elements that are containers and Atom elements that are 
metadata.

== Status ==
New.
== Rationale ==
There are a number of use cases for Atom (e.g., blogs, news, archiving, 
stock quotes, systems monitoring); each has potentially different 
requirements for the presences of certain kinds of metadata. To cater 
to these use cases, and allow implementations to make assumptions about 
feed content when presenting it, we need to identify the *profile* of 
metadata that a feed can be expected to contain.

Furthermore, we need to ship at least one profile with the spec. Right 
now, it's embedded in the schema of what metadata elements are 
required; it would be better to explicitly call it out.

== Proposal ==
1) Change the organisation of the document to this rough outline;
   1.   Introduction
 1.1  Editorial Notes
 1.2  Example
 1.3  Conformance
 1.4  Notational Conventions
   2.   Atom Documents
 2.1 Atom Feed Documents
 2.2 Atom Entry Documents
   3.   Atom Container Elements
 3.1 The "atom:feed" Element
 3.2 The "atom:head" Element
   3.2.1 The "atom:profile" Attribute
 3.3 The "atom:entry" Element
   3.3.1 The "atom:profile" Attribute
   4.   Atom Core Metadata Elements
 4.1  The "atom:title" Element
 4.2  The "atom:id" Element
 4.3  The "atom:link" Element
 4.4  The "atom:updated" Element
 4.5  The "atom:published" Element
 4.6  The "atom:author" Element
 4.7   The "atom:contributor" Element
 4.8   The "atom:host" Element
 4.9   The "atom:copyright" Element
 4.10   The "atom:category" Element
 4.11   The "atom:summary" Element
 4.12   The "atom:content" Element
 4.13   The "atom:introspection" Element
 4.14   The "atom:post" Element
 4.15   The "atom:edit" Element
 4.16   The "atom:tagline" Element
 4.17   The "atom:generator" Element
 4.18   The "atom:info" Element
   5.   Common Atom Constructs
 5.1  Text Constructs
 3.2  Person Constructs
 3.3  Date Constructs
 3.4  Service Constructs
   6.   Atom Profiles
 6.1 The Atom Syndication Profile
 6.2 The Atom Archiving Profile
   7.   Managing Feed State
   8.   Securing Atom Documents
 8.1  Digital Signatures
 8.2  Encryption
   9.   Embedding Atom in Other Formats
   10.   Extending Atom
   11.   IANA Considerations
 11.1  Registry of Link Relations
   12.  Security Considerations
This effectively positions Atom Documents as *containers* of bags of 
metadata, and the children of those containers as *metadata*; the only 
place where we constrain what kind of metadata is required in the feed, 
and how many times each one can appear, is in the profile definition 
(section 6 here).

This flexibility point allows new arrangements of metadata to be 
accommodated as new profiles, while still providing default profiles 
with the spec so that we ship something interoperable.

It also means that the only reason to change the namespace for 
atom:feed, atom:head and atom:entry is if their semantics change; 
likewise, the only reason to change the namespace for one of the 
metadata elements is if its semantics changes.

== Impacts ==
Changes the layout of the specification and the ability to define new 
extensions and profiles; does not affect current implementations at 
all, with the possible exception of changing @version to @profile (see 
below).

== Notes ==
I'm more than happy to submit a personal draft to the WG to show more 
detail of what this would look like.

I'm not stuck on the term "profile"; in fact, I'm happy to ditch 
@profile as long as the semantics of @version are changed to this.

Note that a profile DOES NOT preclude the addition of more metadata; it 
only states what metadata is required to be there. So, you can extend a 
profile, you just can't go below its bar.


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

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


> 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: PaceRemoveInfoAndHost


+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: On organization and abstraction

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: CAP over Atom (PubSub "Common Alerting Protocol" Earthquake Feeds...)


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: 
> 
>   
> 
>  
> 
> /pubsub/topics/301 
> 
>  
> 
> 2005-02-03T21:04:42-05:00 
> 
> 2005-02-03T21:04:42-05:00 
> 
> tag:pubsub.com,2005:CAP:nc51156375 
> 
>  href='http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm'/> 
> 
> An 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.)
>  
> 
>  
> 
> http://www.incident.com/cap/1.0";> 
> 
>   nc51156375 
> 
>   [EMAIL PROTECTED] 
> 
>   2005-02-03T21:04:42-05:00 
> 
>   Test 
> 
>   Alert 
> 
>   Public 
> 
>   nc51156375 
> 
>
> 
> Geo 
> 
> Earthquake 
> 
> Unknown 
> 
> Unknown 
> 
> Unknown 
> 
> Pubsub Earthquake Service 
> 
> Earthquake: M 1.6 (D) NORTHERN CALIFORNIA
> 2005-02-04T02:00:43.100Z 
> 
> An 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.)
>  
> 
>
> http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm 
> 
> EventID=nc51156375 
> 
> Version=1 
> 
> Magnitude=1.6 MD 
> 
> Depth=2 km 
> 
> Verified=N 
> 
>  
> 
>   2 km depth at latitude 38.8168, longitude -122.7915 at
> location: NORTHERN CALIFORNIA 
> 
>   38.8168,-122.7915 0 
> 
>  
> 
>
> 
>  
> 
>  
> 
>  
> 
>   
> 
> 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

+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: PaceFeedState status

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: Feed State [was: Work Queue Rotation #16]

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: Organization Use Cases

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  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: Call for final Paces for consideration: deadline imminent

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: PaceAggregationDocument (was: On organization andabstraction)


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: Entry order


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: PaceRemoveInfoAndHost

+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/

Re: PaceRemoveVersionAttr

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: On organization and abstraction

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 
p

Re: Posted PaceEntryOrder (was Entry order)

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: PaceEnclosuresAndPix status

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: PaceExtendingAtom


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?

 9.2 Extensions To the Atom Vocabulary 
Future versions of this specification may add new elements and 
attributes
to the Atom markup vocabulary.
What about extensions to the specification (as opposed to future 
versions)?

Software written to conform to this version
of the specification will not be able to process such markup 
correctly and,
in fact, will not be able to distinguish it from a markup 
error.  For the
purposes of this discussion, unrecognized markup from the Atom 
vocabulary
will be considered "foreign markup".

Unlike markup from other vocabularies, foreign markup from the 
Atom
vocabulary MAY appear at any location in an Atom document.
*Anywhere*? As the root element? As attributes? As as child of atom:id? 
This is too permissive; it makes it too easy to change the semantics of 
an element or structure in an incompatible manner. Remember, Atom is a 
data format, not a markup format.

When unknown foreign markup is encountered as a child of 
atom:entry,
atom:head, or a Person Construct, software SHOULD bypass the 
markup and any
textual content and MUST NOT change its behavior as a result 
of the
markup's presence.
Good, but what about requiring someone to understand an extension? If 
we don't introduce this before we go 1.0, we won't be able to introduce 
it until Atom 2.0 (I.e., never). This was the wall that HTTP hit, and 
one of the major drivers towards SOAP; I'd really prefer to avoid it 
this time around.

When unknown foreign markup is encountered in a Text Contruct 
or
atom:content element, software SHOULD ignore the markup and 
process any
text content of foreign elements as though the surrounding 
markup were not
present.
This is bad. If I put a strict media type in my atom:content, I expect 
its requirements, restrictions and semantics to be honoured; if I'm 
required to hand it off to a processor, and have that processor 
understand arbitrary extensions, it's too high a bar; many formats and 
processors won't be designed to deal with that. Ignoring the markup but 
processing the text may have unintended consequences.

Might I suggest:
Extensions are allowed as:
  - Child elements of atom:head
  - Child elements of atom:entry
  - Child elements of elements which are Person constructs
  - Where particular elements defined by extension explicitly allow it.
Anywhere else, it's not an Atom Document.
Furthermore, children of atom:head and atom:entry MAY have a 
mustUnderstand attribute, with the usual semantics.

Finally, extensions MUST NOT contradict their containing elements' 
semantics.

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

Re: On organization and abstraction

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

 f1
 
  f1
  e1
  
 
  f1
  e2
  
 
  f2
  e3
  
 
you'd have

 f1
 f1
  e1
  e2
  
 f2>
  e3
  
 
Which on the face of it seems like an improvement. -Tim

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

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: PaceAggregationDocument (was: On organization and abstraction)

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  to
the feed itself.

e.

Re: On organization and abstraction

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: Organization Use Cases

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

>> I believe there is a proposal for a  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

and 

(guessing at the @rel values)

e.

Re: On organization and abstraction

2005-02-03 Thread Graham

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.

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.

Whereas something like Feedster search results are a collection of 
entries that come from various blogs. It's the entries the user is 
interested in, and knowing which feed they came from is essentially 
extra metadata about the entry.

Graham

smime.p7s
Description: S/MIME cryptographic signature

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

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:

/pubsub/topics/301

2005-02-03T21:04:42-05:00

tag:pubsub.com,2005:CAP:nc51156375

An 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.)

nc51156375

[EMAIL PROTECTED]

2005-02-03T21:04:42-05:00

Test

Alert

Public

nc51156375

Geo

Earthquake

Unknown

Pubsub Earthquake Service

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

An 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.)

http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm

EventID=nc51156375

Version=1

Magnitude=1.6 MD

Depth=2 km

Verified=N

2 km depth at latitude 38.8168, longitude -122.7915 at
location: NORTHERN CALIFORNIA

38.8168,-122.7915 0

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

Re: Organization Use Cases

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  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

Re: On organization and abstraction

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: Call for final Paces for consideration: deadline imminent

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

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 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: Organization Use Cases (was: Re: Format spec vs Protocol spec)

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  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

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: 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: RELAX NG Grammar question

/ 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: Exactly one atom:contributor?


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

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?

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

Updated Atom grammar

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: atom:content in atom:entry

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

atom:content in atom:entry

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: 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  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  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, 
 is probably better--using ) 
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.

Re: Exactly one atom:contributor?

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: PaceRemoveVersionAttr

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?

Exactly one atom:contributor?

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.

Be seeing you,
  norm

-- 
Norman Walsh <[EMAIL PROTECTED]> | The First Amendment is often
http://nwalsh.com/| inconvenient. But that is besides the
  | point. Inconvenience does not absolve
  | the government of its obligation to
  | tolerate speech.--Justice Anthony
  | Kennedy, in 91-155


pgpIeHi1XWK0j.pgp
Description: PGP signature

RELAX NG Grammar question

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 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

PaceRemoveVersionAttr

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: RELAX-NG bug in draft-05?

/ 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 ValÃry


pgpaFM1Y9BUm2.pgp
Description: PGP signature

Re: tagline -> subtitle

/ 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: Trial format-05 atom feed

/ Tim Bray <[EMAIL PROTECTED]> was heard to say:
| On Feb 2, 2005, at 4:29 AM, Sam Ruby wrote:
|
|>> Norm's RNC schema was very valuable in debugging, not that there
|>> were many bugs.  Check it out at
|>> http://www.tbray.org/ongoing/ongoing.atom
|>
|> the xmlns and version indicate format-04.
|
| I didn't want to fiddle with Norm's RNC.

I've just this minute decided that instead of trying to comment on
the -05 draft, about which I have seen a huge number of comments,
I'll go off and work on the RNG, starting with the test collection
Sam pointed me to last time I asked.

Be seeing you,
  norm

-- 
Norman Walsh <[EMAIL PROTECTED]> | In the life of saints, technically so
http://nwalsh.com/| called, the spiritual facilities are
  | strong, but what gives the impression
  | of extravagance proves usually on
  | examination to be a relative deficiency
  | of intellect.--William James


pgpr7GIbfhpGS.pgp
Description: PGP signature

Re: PaceCollection

On 4/2/05 4:49 AM, "James Snell" <[EMAIL PROTECTED]> wrote:

> 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.

Fruit & veg departments in grocery stores are named "fruit & veg". Very few
of them are named "potatoes and bananas", even though "potatoes" and
"bananas" are words with well-known and well-understood meaning.

e.

Re: PaceEnclosuresAndPix status

/ Tim Bray <[EMAIL PROTECTED]> was heard to say:
| On Jan 26, 2005, at 7:16 PM, Graham wrote:
|
|> Can you outline the problem[s] that having a icon link tag in the
|> feed might cause? HTML already has a meta tag for it, so it seems
|> like a simple feature-parity issue.
|
| Well, I don't think we're after feature-parity with HTML :)
|
| Seriously, the existing "HTML feature" by which we mean conventional
| web-browser feature, works by fetching /favicon.ico; so Atom client

I thought modern browsers followed the "icon" link:

  

(in preference to, if not instead of, attempting the grotesque hack
of grabbing /favicon.ico)

Be seeing you,
  norm

-- 
Norman Walsh <[EMAIL PROTECTED]> | You must not think me necessarily
http://nwalsh.com/| foolish because I am facetious, nor
  | will I consider you necessarily wise
  | because you are grave.--Sydney Smith


pgppRT92QZlHc.pgp
Description: PGP signature

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

On Thursday, February 3, 2005, at 01:13  PM, Henri Sivonen wrote:
On Feb 3, 2005, at 20:20, Walter Underwood wrote:
--On February 3, 2005 1:31:45 PM +0200 Henri Sivonen 
<[EMAIL PROTECTED]> wrote:
Backups. Dump and reload for an upgrade with a DB schema change.
Consistent save from a live database (hold a read lock while you dump 
the
archive). Insurance against your blog service going away on short 
notice.
Sarbanes-Oxley compliance for corporate blogs (internal and external).
What value does Atom as yet another container format add over .zip 
(perhaps with a metadata manifest as in .jar) or .mht?
It's readable by feed readers.
I think we're not all talking about the same meaning of the word 
"archive".  We aren't talking about what you do when you compress a 
bunch of files into a zip, tgz, sit...file.  We're not talking about 
Base64ing all your photos so that you can stuff them into a single Atom 
document for backup.  Unless I'm mistaken, we're talking essentially 
about using (relatively) static Atom documents to store the portions of 
a stream of entries (aka a "feed") that have passed through the 
"sliding window".

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

2005-02-03 Thread Henri Sivonen

On Feb 3, 2005, at 20:20, Walter Underwood wrote:
--On February 3, 2005 1:31:45 PM +0200 Henri Sivonen <[EMAIL PROTECTED]> 
wrote:
What's the *point* in archiving with Atom compared to eg. a zip 
archive with
some HTML or XHTML files in it (with relative links and a stipulation 
that
index.html and index.xhtml are magic names)?
Cross-platform dump and load. Saving data that is in the database and 
not
in the HTML.
Why couldn't you dump from a database to an (X)HTML entry in a zip 
archive if you can dump into a 'content' element in an Atom file?

Backups. Dump and reload for an upgrade with a DB schema change.
Consistent save from a live database (hold a read lock while you dump 
the
archive). Insurance against your blog service going away on short 
notice.
Sarbanes-Oxley compliance for corporate blogs (internal and external).
What value does Atom as yet another container format add over .zip 
(perhaps with a metadata manifest as in .jar) or .mht?

Why would anyone, who so far has not implemented zip/mht dump and load, 
implement Atom dump and load?

(Compared to all competing Base64-in-text-or-XML aggregate document 
formats, zip-based OOo files are surprisingly elegant.)

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

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

2005-02-03 Thread Walter Underwood

--On February 3, 2005 1:31:45 PM +0200 Henri Sivonen <[EMAIL PROTECTED]> wrote:
> On Feb 3, 2005, at 08:09, James Snell wrote:
> 
>> What is the model for archiving with Atom?
> 
> What's the *point* in archiving with Atom compared to eg. a zip archive with
> some HTML or XHTML files in it (with relative links and a stipulation that
> index.html and index.xhtml are magic names)?

Cross-platform dump and load. Saving data that is in the database and not
in the HTML. Backups. Dump and reload for an upgrade with a DB schema change.
Consistent save from a live database (hold a read lock while you dump the
archive). Insurance against your blog service going away on short notice.
Sarbanes-Oxley compliance for corporate blogs (internal and external).

And of course, so Brewster Kahle can keep a copy. The Wayback Machine
has saved my butt a couple of times.

wunder
--
Walter Underwood
Principal Architect, Verity

Re: PaceCollection

On Thursday, February 3, 2005, at 10:49  AM, James Snell wrote:
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.

...
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.
I agree.  The question whether the impact of the first two or the 
impact of the last is greater.  I suspect that many of the people 
already familiar with the term "feed" would very quickly realize that 
"collection" is what used to be called "feed" (which is what used to be 
called "rss" in past lives)--much more quickly than people just getting 
into syndication (which, BTW, I don't think is that great a term, but 
that's another story) would be able to wrap their minds around "feed" 
as opposed to "collection".

That said, I don't feel strongly about this, so I'll quit here.

Re: PaceEntriesElement

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: PaceCollection


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.

> 
> 
> This is my blog
> 2004-01-25T10:04:00+
> 
> 
> Johhny learns to read
> 2004-01-25T10:04:00+
> [...]
> 
> 
> I resolve to blog
> 2004-01-24T14:02:00+
> [...]
> 
> 
> 
> 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: sub feeds (was Re: Call for final Paces for consideration: deadline imminent)

Eric Scheid wrote:
On 3/2/05 7:18 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
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.
I'm sorry, the whole point of my pace is that collections are resources. 
This is obviosly true. You just have to look at the flurry of Paces that 
resulted with hacky link relations to see that it's true.

Robert Sayre

Re: PaceCollection

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:



This is my blog
2004-01-25T10:04:00+


Johhny learns to read
2004-01-25T10:04:00+
[...]


I resolve to blog
2004-01-24T14:02:00+
[...]


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: Thinking ahead: Atom Extension Proposals on the Wiki?


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]

PaceCommentFeeds posted

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: 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
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

2005-02-03 Thread Henri Sivonen

On Feb 3, 2005, at 08:09, James Snell wrote:
What is the model for archiving with Atom?
What's the *point* in archiving with Atom compared to eg. a zip archive 
with some HTML or XHTML files in it (with relative links and a 
stipulation that index.html and index.xhtml are magic names)?

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

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: Principled Reasoning. was: PaceAggregationDocument posted

2005-02-03 Thread Henry Story

Thanks these are much more helpful in working out the 
Principles/requirements
that guide your thinking.

Here are two requirements that make sense to me and seem close to giving
the same results in preferences that you have:
P1. Atom documents should be easily parsable.
P2. Atom documents should be easily updatable.
I think P2 is especially difficult for a format that would be recursive
such as
   feed
 entry1
 entry2
entry response1
entry response1.1
entry response2
as it might force updates to add xml to the middle of an xml document
and so force the whole document to be regenerated. Placing entries in
a sequence and having them refer to each other by reference
makes it much easier to update your original document.
In RDF this would be similar to the TRiX or the RPV (presented by
Tim Bray) proposals [1].
And this comparison may lead us to see perhaps how to find an
agreement with the intuitions behind the paceFeedRecursive or "Entry
is a subclass of Feed" type proposals. Those proposals are put
forward from the point of view of:
P3. Simple is beautiful
But perhaps the simplicity that is searched for there is a
simplicity in the model. Indeed from a programmatic point
of view nothings is quite as beautiful as a nice recursive
algorithm. But perhaps we can have both points of views live
happily together, and perhaps the rdf experience points out
how to do this: by separating the syntax from the model.
Let us imagine we have a nice and simple model where
for example a Feed is a subclass of an Entry. We could
present this model very precisely in an OWL ontology in a
recursive way.
But we could then limit the ways to write out this model
with a Relax NG schema. Atom would then have 1. a simple model
and 2. a simple syntax.
Perfection would then be had by making absolutely clear
that the model is a model of the syntax allowed by the relaxng
compliant document, by making sure the relaxng compliant document
also be a rdf/xml document.
Henry Story
http://bblfish.net/
[1] http://www.fakeroot.net/sw/rdf-formats-20040717/#rpv


On 1 Feb 2005, at 21:05, Antone Roundy wrote:
On Tuesday, February 1, 2005, at 06:08  AM, Henry Story wrote:
...
Without taking the trouble to purchase and read the book you pointed 
to, here is my reasoning:

Antone Roundy wrote:
My preferences:
+1: Current draft or PaceAggregationDocument (with or without 
atom:feed/atom:head and with or without metadata for 
atom:aggregation (atom:aggregation/atom:head?))
Stable paths to the elements of a feed.  Greatest 
simplicity--certainly the way that I implement my code, these are the 
simplest.

+0.5: PaceFeedRecursive without any more indirection than we 
already have, and only one level of recursion
Less stable paths to elements since you don't know in advance whether 
the entries will be in the outermost feed, or whether some or all of 
them will be inside another feed layer.

-0.8: Real RDF
I think we've discussed this one enough--RDF adds overhead that I 
don't value.  Others do.  I don't.

-1: PaceFeedRecursive as it stands (no extra indirection, but 
unlimited levels of recursion)
I don't want to have to deal with the added complexity of potentially 
unlimited recursion, nor do I see value in allowing it.  Sure, it can 
show you the long list of feeds that an entry traversed to get from 
its original feed to the current feed, but for those who value that 
more than I do, there MUST be a better way to do it.

-1.5: "add an attribute to atom:entry that indicates whether it 
refers to an instance of entry or another feed"
I'm not entirely sure what is intended by this, but it sounds like a 
combination of unlimited recursion and not even knowing whether and 
entry is an entry or a feed without examining it's attributes.  I 
assume this is basically "a feed is an entry, so let's use the same 
element for both"?

-2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and 
atom:content
Potentially unlimited recursion, and potentially significantly more 
connections required to get a feed.  This may not be a big deal to 
applications that don't hand of HTML content to some widget for 
handling, and thus have to handle the details of loading images and 
such themselves, but for applications that do, it's much simpler to be 
able to get everything that they need to manipulate with one request 
and be done with it. We already have indirection for , which 
I personally would be happier without. I'd like to avoid adding more.

Re: PaceMustBeWellFormed

2005-02-03 Thread =?ISO-8859-1?Q?Bill_de_h=D3ra?=

Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceMustBeWellFormed
[...]
Stretching, extending, or profiling the XML specification and/or RFC3023 
 to lend weight to the text is totally inappropriate. All we can do is 
say "MUST" and define our own terms to the extent that we can.
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?
For example,
[[[
N Processing Atom markup
N.1 Determining the character encoding of an Atom feed
The concept of XML well-formedness relies on first determining the 
character encoding of the XML document. The rules for determining the 
character encoding of an Atom feed served over HTTP are no different to 
determining the character encoding of any XML document served over HTTP.
Those rules are defined by RFC 3023 and are considered normative by this 
specification. They are summarized here as there has been confusion over 
how RFC 3023 should be interpreted. In order to comply with RFC 3023:

 1. When serving an Atom feed, it is RECOMMENDED that publishers 
include the charset parameter along with the media type in the 
Content-type HTTP header.  If the charset parameter is present, clients 
MUST parse the Atom feed in that charset, ignoring any charset declared 
in the encoding attribute of the XML declaration.

 1. Publishers SHOULD serve Atom feeds with the media type 
"application/atom+xml" (registered in Section @@@ of this document).

 1. If a publisher wishes to serve an Atom feed over HTTP, but for some 
reason they are unable to use the "application/atom+xml" media type, the 
publisher SHOULD use "application/xml".

 1. Clients MUST determine the character encoding as per RFC 3023 or 
its successor.

 1. If a publisher is unable to serve their Atom feed with a 
Content-Type of "application/atom+xml" or "application/xml", they MAY 
use "text/xml".  Note: according to RFC 3023, XML documents served as 
"text/xml" with no charset parameter have a character encoding of 
"us-ascii".

 1. When serving an Atom feed as "text/xml", publishers MUST escape all 
non-US-ASCII characters as [http://www.w3.org/TR/REC-xml/#sec-references 
character references] to comply with RFC 3023.  For example, 'ø' 
for the character 'ø'.

1. When retrieving an Atom feed served with a Content-type of "text/xml":
  1. clients MUST parse it with a "us-ascii" encoding in order .
  1. if such a feed contains non-US-ASCII characters, and clients MUST 
reject it as non-well-formed.

 1. Publishers MUST NOT serve Atom feeds with a media type other than 
the XML media types defined in RFC 3023 or its successor.  In particular 
Atom publishers are expected to note that "text/plain" is not an 
appropriate media type for an Atom feed.

1. When retrieving an Atom feed served with a non-XML media type,, 
clients MUST reject it as non-well-formed.
]]]

While I think we have to be realistic about people do with markup in the 
 wild, I find nothing above controversial or overconstraining in the 
above from a specification viewpoint. It's being worded in such a way 
that implementors can make a decision to comply with RFC 3023 or not. 
After a time, we'll be able to see whether or not RFC 3023 is actually 
useful, but right now, I don't see how we can punt on this matter.

cheers
Bill

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: 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: 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: ServiceElement and other matters

2005-02-03 Thread Henry Story

In RDF/model terms the id is a functional property relating an
Entry/Head and a resource (see my AtomOWL pace) It is not strictly
an identity property (which would require it to be functional, inverse
functional, symmetric and transitive)
This therefore gives you no allowance to merge the entries.
You can sort them by date or other ways if you wish though.
Henry
On 3 Feb 2005, at 09:18, Eric Scheid wrote:
On 3/2/05 6:50 PM, "James Snell" <[EMAIL PROTECTED]> wrote:
2. Entry id's.  Ok, so they are supposed to be "universally unique".
That's all good and fine.  But what if... hypothetically... my Atom
reader gets two copies of the same Entry with different metadata.
They are the same entry because they have the same id.  One of the
versions of the entry differs from the other in that some feed
aggregator somewhere added some additional pieces of metadata to it.
Do I: a) silently reject one of the entries, b) merge the metadata of
the two entry instances into a single logical entry, c) throw up on
the user.
The thinking so far has been that you would discard the one which has 
the
older  datestamp. If the  values are equal, then any
differences were not considered "significant" by the publisher, and so 
you
can silently discard either one.

You wouldn't merge the versions, apparently.
e.

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


On Thu, 03 Feb 2005 19:22:10 +1100, Eric Scheid
<[EMAIL PROTECTED]> wrote:
> 
> 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.
> 

+1 on "entries can describe feeds, not actually be feeds".  An entry
can reference a feed, but is not the feed itself.

> e.
> 
> 


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

Re: ServiceElement and other matters

On 3/2/05 6:50 PM, "James Snell" <[EMAIL PROTECTED]> wrote:

> 2. Entry id's.  Ok, so they are supposed to be "universally unique".
> That's all good and fine.  But what if... hypothetically... my Atom
> reader gets two copies of the same Entry with different metadata.
> They are the same entry because they have the same id.  One of the
> versions of the entry differs from the other in that some feed
> aggregator somewhere added some additional pieces of metadata to it.
> Do I: a) silently reject one of the entries, b) merge the metadata of
> the two entry instances into a single logical entry, c) throw up on
> the user.

The thinking so far has been that you would discard the one which has the
older  datestamp. If the  values are equal, then any
differences were not considered "significant" by the publisher, and so you
can silently discard either one.

You wouldn't merge the versions, apparently.

e.

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

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.

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