Subject: PaceProfile - new

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Feb 2005 21:46:20 -0800

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/

---

From: James Snell <[email-masked]>
Date: Thu, 3 Feb 2005 22:20:18 -0800

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.

<feed profile="syndication">...</feed>
<feed profile="archiving">...</feed>
<feed profile="aggregation">...</feed>
...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.

<feed profiles="syndication aggregation archiving">...</feed>

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

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 04 Feb 2005 09:53:19 +0000

James Snell wrote:
> [...]

I'm -1 on this pace.

One concern I have is that I don't want to see feed data constrained 
according to usecases (ie system monitoring); that makes the data less 
useful and goes down the route of publishers telling clients how to 
write their applications or making assumptions on how data will be 
processed downstream. While I believe that claiming Atom is a container 
for metadata is good, I doubt that profiling represents a more flexible 
approach - it moves us away from agents coordinating together to agents 
enforcing policy on one another via a profiling mechanism.

The place to put such constraints is on the range and domain of the 
metadata properties or in themed extensions - RDF clearly gets this 
right as do RSS1.0 modules. I have doubts about profiles will work out 
as they seem to range over the entire feed rather than an item of metadata.

As for @version being meaningless; it's not. It's sufficient for someone 
to swap in a code handler by switching on type. It might not have any 
forward or back compatible semantics but it is does signify wrt other 
versions. The @profile (as presented above) has no more or less meaning 
that @version.

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Fri, 04 Feb 2005 21:21:34 +1100

I just had a thought (astounding!)

If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone to produce feeds with any ad hoc element, even
elements which are not in any updated Atom specification.

How would a feed validator react to something like this:

  <feed xmlns="http://purl.org/atom/ns#1.0">
    <head>...</head>
    <entry>
        <foo>...</foo>
        ...
    </entry>
  </feed>

It can't say <foo> isn't allowed in this feed, because it doesn't know if
<foo> was introduced in Atom 1.1. If the validator is updated to know about
Atom 1.1, the same problem exists: it doesn't know if it came from 1.2.

One of the criticisms I've seen for OPML is that anyone can add any element
or attribution of their own invention anywhere any time, and that this has
led to xml-soup.

Do we want to see the same future for Atom?

e.

---

From: Sam Ruby <[email-masked]>
Date: Fri, 04 Feb 2005 07:48:42 -0500

> I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm.

I have a spam throttle that limits the number of unique pages a person 
who is not logged in can edit per hour.  I'll send you login info.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Fri, 04 Feb 2005 10:00:24 -0500

> Do we want to see the same future for Atom?

Whether the feedvalidator flags such an element or not, the spec 
declares (or will declare once the spec is updated to reflect the last 
round from the workgroup) such elements as invalid.

Furthermore, having things like the feedvalidator flag unknown elements 
in the Atom namespace as invalid is exactly what makes it safe for 
future authors or revisions of the Atom specification to add new 
elements in the Atom namespace without fear of conflicting with existing 
feeds.

What this does mean is that the feedvalidator either needs to be updated 
when new versions of Atom come out, or become increasingly irrelevant 
and obsolete as new validators assume this role (possibly something as 
simple as a RelaxNG schema).

- Sam Ruby

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 07:41:33 -0800

Bill,

I'm sorry, I don't think I get what you're saying; the words all make 
sense, but I don't know how you got here.

Atom currently constrains feed data (e.g., you MUST have a title, there 
MUST only be one) based on the most common use case; bloggling/news 
syndication. How does this move towards "agents enforcing policy on one 
another?" If anything, the Pace makes it *less* likely that publishers 
will make assumptions about how data will be processed downstream; as 
Atom is currently specified, there are lots of such assumptions built 
in.

The Pace doesn't place any requirements on Atom Processors WRT 
@profile; it's just an advisory flag that tells it what kinds of 
metadata it can count on appearing in the feed.

On Feb 4, 2005, at 1:53 AM, Bill de hÓra wrote:

> processed downstream. While I believe that claiming Atom is a 
> container for metadata is good, I doubt that profiling represents a 
> more flexible approach - it moves us away from agents coordinating 
> together to agents enforcing policy on one another via a profiling 
> mechanism.

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 04 Feb 2005 16:15:39 +0000

Mark Nottingham wrote:
> [../]
> The Pace doesn't place any requirements on Atom Processors WRT @profile; 
> it's just an advisory flag that tells it what kinds of metadata it can 
> count on appearing in the feed.

Ok, I'll calm down and try again.

If the advisory @profile scopes at the level of the feed, I think that's 
too broad a scope. It needs to scope at the level of the entry, or it's 
liable to becomes meaningless when entries are mixed and matched. I can 
barely figure out how to class individual entries, never mind entire 
feeds. Maybe there's a use case I'm not getting.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 14:47:13 -0800

Hmm. I'm thinking of profiles as fairly coarse-grained things; so 
coarse-grained, it wouldn't make sense to mix-and-match them in a 
single document (or, if you do, you either don't use a profile, or you 
invent a new one).

I.e., does it make sense to mix a "stock quote" entry with a "systems 
monitoring" or "blog" entry? How would a UA present this?

On Feb 4, 2005, at 8:15 AM, Bill de hÓra wrote:

> If the advisory @profile scopes at the level of the feed, I think 
> that's too broad a scope. It needs to scope at the level of the entry, 
> or it's liable to becomes meaningless when entries are mixed and 
> matched. I can barely figure out how to class individual entries, 
> never mind entire feeds. Maybe there's a use case I'm not getting.

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

---

From: James M Snell <[email-masked]>
Date: Fri, 04 Feb 2005 15:14:52 -0800

It would make sense to mix "syndication", "archive", "aggregation", etc.
  In other words, some profiles would make sense to mix together.

Entry-scoped profile makes a LOT of sense.

@profile attribute on the feed level applies only to the feed and is
used to identify the collection(s) of metadata elements used in the feed.

@profile attribute on the entry level applies only to the entry and is
used to identify the collection(s) of metadata elements used in the entry.

<feed profile="syndication aggregation">
   ...
   <entry profile="blog">
    ...
   </entry>
</feed>

<feed profile="archive">
   ...
   <entry profile="blog archive">
     ...
   </entry>
</feed>

Other than helping to identify the collection of metadata elements,
another nice about this approach is that it allows the producer of the
feed to explicitly indicate the purpose of the feed.  Feeds that are
intended for archiving use can be handled differently than feeds that
are intended for syndication.  Entries that use a blog profile can be
handled differently than entries used, for instance, to express CAP
Alert information, etc.

As for profiles that don't make sense to mix and match, leave the
decision about whether to mix and match up to the producer of the
feed/entry.  If the UA detects that a feed/entry uses a combination of
profiles that are contradictory, the UA can choose to either reject the
item or choose to ignore one or both of the profiles and attempt to deal
with the entry by falling back on the default core metadata elements.
If a profile is indicated that the UA does not understand, the UA could
safely ignore the profile and just work off the minimally required core
metadata elements.

- James M Snell

Mark Nottingham wrote:
> coarse-grained, it wouldn't make sense to mix-and-match them in a single 
> document (or, if you do, you either don't use a profile, or you invent a 
> new one).
>

---

From: James Snell <[email-masked]>
Date: Fri, 4 Feb 2005 15:35:56 -0800

Absolutely, there would be a core default profile defined in the Atom
syntax spec.  @profiles="core syndication" @profiles="core blog", etc.

On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham <[email-masked]> wrote:
> 
> On Feb 4, 2005, at 3:13 PM, James M Snell wrote:
> 
> >  If a profile is indicated that the UA does not understand, the UA
> > could safely ignore the profile and just work off the minimally
> > required core metadata elements.
> 
> Ah, that's the rub; I'm trying to say that that set of 'core' elements
> is, in and of itself, a profile.
> 
> 
> --

---

From: James M Snell <[email-masked]>
Date: Fri, 04 Feb 2005 16:04:07 -0800

True, but I don't think it needs to be anything all that complicated. A 
profile defines what metadata elements [must|must not|may|may 
not|should|should not] be found in that particular entry/feed.  What 
more beyond that would be required?

- James M Snell

Mark Nottingham wrote:
> but then you get into a composition model for the requirements of 
> profiles...
> 
> 
> On Feb 4, 2005, at 3:35 PM, James Snell wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 16:09:18 -0800

I was thinking of profiles only specifying:
   - what metadata is required to be present
   - optionally for each one that's required, the maximum number that 
can be present

If profiles are constrained as such, they're pretty trivial to compose; 
if we allow them to say what *isn't* allowed to be there, it gets much 
more complex. It also goes against the spirit of extensibility...

On Feb 4, 2005, at 4:04 PM, James M Snell wrote:

> True, but I don't think it needs to be anything all that complicated. 
> A profile defines what metadata elements [must|must not|may|may

---

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 01:09:36 +0000

On 5 Feb 2005, at 12:09 am, Mark Nottingham wrote:

> If profiles are constrained as such, they're pretty trivial to 
> compose; if we allow them to say what *isn't* allowed to be there, it 
> gets much more complex. It also goes against the spirit of 
> extensibility...

I fail to see what constraints in the current version justify different 
profiles, especially given the inevitable breaks in interop. Can you 
give us some examples?

Graham