Ah, fond memories:
http://intertwingly.net/wiki/pie/PaceProfileAttribute
Putting it in as a media type parameter is interesting, but I think it
needs to be in the document as well.
What I *really* think we need to do is define the current use of Atom
as a profile (which is what I suggested many years ago), so that use
cases that don't require an updated element, or a title element, etc.,
don't have to have one that carries useless -- or worse, misleading --
information.
However, doing that would likely require defining a new namespace and
media type for Atom, since doing so wouldn't be backwards-compatible.
Personally, I think it's worth it, provided we can find enough other
clarifications/fixes to bundle in to make a new namespace attractive
enough.
Cheers,
P.S. Using RFC#### as a convention effectively prevents any recognised
standards org from building on top of Atom in this fashion; use a
registry. Also, it will doubtless lead to the dreaded RFC10K problem...
On 13/06/2009, at 8:52 AM, James M Snell wrote:
Well, the second half of my work week ended up getting preempted by
a stupid primary development workstation that decided to go kaput on
me so I have not yet had the opportunity to write up the Profile
media type extension spec. While I'm waiting for the last few apps
to download so I can reinstall them, I figured it would at least be
helpful for me to write up my thoughts and I'll get the draft
published next week.
Basically, a "Profile" is going to be some kind of document that
provides implementation guidelines for an Atom app. It will define a
specific use of Atom along with whatever extensions, assumptions,
options, etc necessary for that. For instance, one could easily
imagine a "Blogging" profile for Atom that describes in detail how
to use the Atom publishing protocol specifically for Weblogs, etc.
Every Profile document will be associated with an identifier. The
identifier is either a short name or an IRI following the same
pattern as atom:link/@rel values. However, use of the short names
will be restricted and must follow a strict convention...
Specifically, only Profiles published through the IETF process will
be allowed short names. For a Profile published as an Internet-
Draft, the profile identifier is the document name. For instance,
given a theoretical draft-snell-profile-blogging-01.txt, the
identifier for the Profile is "draft-snell-profile-blogging-01".
For a Profile published as an RFC, the project identifier is the
RFC# in the pattern "RFC####". The shortnames are always case-
insensitive so "rfc9999" is equivalent to "RFC9999" or "Rfc9999",
etc. For all other Profiles, the identifier is an absolute IRI that
SHOULD be dereference-able to retrieve the Profile document.
In all Atom media types, the profile parameter is an optional
quoted, whitespace delimited list of profile identifiers, e.g.
application/atom+xml;
profile="RFC9999
draft-snell-profile-blogging-01
http://example.org/profile/foo";
Someone looking at this media type can determine that the Atom
document in question conforms to three profiles identified by
"RFC999", "draft-snell-profile-blogging-01", and "http://example.org/profile/foo
". What "Conformance" means depends entirely on the profile.
The profile parameter is intended only as a hint. An application can
use it to help make decisions about a linked resource, etc but the
presence of a particular profile identifier in the media type does
not place any obligations on the application.
As always, comments are requested and welcomed.
- James
--
Mark Nottingham http://www.mnot.net/
