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) 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 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/ > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
