Paul Hoffman wrote:
>
> -1 because it doesn't feel like it belongs in the core. That is, when
> more developers have real profiles that they want to differentiate from
> the atom core, adding a @profile attribute seems like a good extension.
Hmm. the challenge with this assertion is that the atom s
-1 because it doesn't feel like it belongs in the core. That is, when
more developers have real profiles that they want to differentiate
from the atom core, adding a @profile attribute seems like a good
extension.
--Paul Hoffman, Director
--Internet Mail Consortium
I'm in favor of profiles, just -1 to allowing @profile on sub-elements.
So I prefer PaceProfile to PaceProfileAttribute.
On Monday, February 7, 2005, at 02:17 PM, James M Snell wrote:
This is entirely possible also. Just to be clear tho, you're not
-1'ing the idea of pro
This is entirely possible also. Just to be clear tho, you're not -1'ing
the idea of profiles, just the allowing of the @profile attribute on
sub-elements (e.g. entries contained in feeds) correct? This is an
important distinction because I'm definitely not married to the syntax
as presented b
-1: One profile (or maybe set of profiles) per document is better in my
opinion. If an aggregator aggregates entries with different profiles,
it can either fix them up as needed to conform to a common profile, or
if multiple profiles can be specified at the top level, declare the
profiles for
On 6/2/05 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> atom:feed and atom:entry elements MAY have a "profile" attribute whose
> value is a list of names or URI's identifying one or more metadata
> profiles that have been applied to the feed or entry. A profile is a
> description what m
This is a modified version of Mark Nottingham's initial idea that
reflects my thinking on the subject as developed through the mailing
list discussion. I posted it as PaceProfileAttribute as opposed to
Mark's initial PaceProfile in case he wanted to go ahead and attempt to
submit hi
