Subject: PaceProfile updated

From: Mark Nottingham <[email-masked]>
Date: Sat, 12 Feb 2005 16:49:10 -0800

Apologies for the delay; I've been sick since Monday.

I've revised PaceProfile to make it more complete, as requested.

   http://www.intertwingly.net/wiki/pie/PaceProfile

The biggest change from the previous approach is that cardinality of 
metadata elements is specified by those elements, in the form "When 
present, atom:title MUST occur exactly once." Profiles only constrain 
what metadata elements are required in the feed.

Regards,

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

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 13 Feb 2005 11:03:02 +0100

Mark Nottingham wrote:
> present, atom:title MUST occur exactly once." Profiles only
> constrain what metadata elements are required in the feed.

Do I understand it correctly that the profiles themselves still need to
be discussed?

Also, you can not mix profiles like you can in HTML 4.01? (Although
there it is underdefined.)

I would also like to know what is meant exactly with metadata elements.
Which elements does that include and which are excluded.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Eric Scheid <[email-masked]>
Date: Sun, 13 Feb 2005 21:52:44 +1100

> what metadata elements are required in the feed.

does this mean then that someone can't make a profile for bilingual feeds?

e.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 13 Feb 2005 09:29:52 -0800

> does this mean then that someone can't make a profile for bilingual 

It depends on the definitions of the individual metadata elements. If 
they allow multiple instances, yes; otherwise, you'd need to define new 
ones.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 13 Feb 2005 09:31:28 -0800

> Do I understand it correctly that the profiles themselves still need to

That's the purpose of this Pace. Are you asking something else?

> there it is underdefined.)

That's my intention in this proposal. I'm amenable to allowing 
multiples, though, as mentioned in the notes.

> Which elements does that include and which are excluded.

All of those that are children of atom:head and atom:entry are metadata.

---

From: James M Snell <[email-masked]>
Date: Sun, 13 Feb 2005 19:42:35 -0800

Mark,

First off, I hope you're feeling better.  Second, thanks for updating 
PaceProfile ... I was looking forward to learning more about where your 
head was at with regards to this.

First, not counting document organization, the key differences between 
what you're proposing and my PaceProfileAttribute proposal appear to be:

1. PaceProfileAttribute = @profile at feed & entry level
    PaceProfile          = @profile on the head element

2. PaceProfileAttribute = @profile may specify multiple profiles
    PaceProfile          = @profile specifies a single profile

3. PaceProfileAttribute = Profile defines required elements AND
                           cardinality
    PaceProfile          = Profile defines required elements,
                           cardinality is determine by element definition

4. PaceProfileAttribute = Profiles are absolute URI's or IANA
                           registered names
    PaceProfile          = absolute URI

Ok, for #1, in my opinion, @profile on the entry level is useful given 
the ability for entries to exist independently of a feed.  For instance, 
when using the Atom API to post a new entry, @profile on the entry
would allow me to specify a profile (containment requirements) for the 
entry before that entry is ever made part of a feed.  If we are going to 
allow entries to exist independently of a feed, @profile on entry should 
be supported.

For #2, the utility of multiple profiles is somewhat nebulous but I do 
think it would be useful.  Essentially, for interoperability sake, it 
would be better to mix-and-match from a pool of known profiles than to 
create new customized profiles with new unknown identifiers.

For #3, restricting profile to what elements are required while keeping 
cardinality as part of the element definition does not seem logical to 
me. Look at XML Schema as an example...

   <xs:element name="foo"/>
   <xs:element name="bar">
     <xs:complexType>
       <xs:sequence>
         <xs:element ref="foo" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>

Cardinality is a property of the containment requirements, not of the 
element definition.  It wouldn't make any sense to do the following, as 
each element that may choose to contain foo will specify whatever 
cardinality makes sense in it's specific context.

   <xs:element name="foo" minOccurs="0" maxOccurs="unbounded"/>
   <xs:element name="bar">
     <xs:complexType>
       <xs:sequence>
         <xs:element ref="foo" />
       </xs:sequence>
     </xs:complexType>
   </xs:element>

Bottom line, I'd much rather keep cardinality in the profile.

For #4, for interoperability sake, I think it would be a good idea for 
there to be an officially recognized set of known profiles, as well as 
the ability to allow folks to extend the profiles in an ad hoc manner, 
just as has been done for the link @rel attribute.  Sure, it adds a 
degree of complexity, and process, but it also adds a higher degree of 
stability and interoperability.

Finally, I see now discussion of interoperablity concerns in your 
proposal.  Any proper treatment of profiles should at least touch on the 
topic of compatibility with the "core" profile"  PaceProfileAttribute, 
for instance, strongly recommends that any new profiles be created so 
that they are backwards compatible with the core while acknowledging 
that incompatible profiles could be created.  The proposal also states 
that @profile is informational only and does not impose any 
implementation requirements on the part of implementors.  Things aren't 
so clear with PaceProfile.  Is the @profile attribute normative? Are 
implementations *required* to validate against the profile?  What should 
an implementor do if an unknown profile is found?

- James M Snell

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 13 Feb 2005 20:07:20 -0800

On Feb 13, 2005, at 7:42 PM, James M Snell wrote:

> PaceProfile ... I was looking forward to learning more about where 
> your head was at with regards to this.

Thanks! I'm feeling much better; still not 100%, but miles away from 
where I was last week.

>    PaceProfile          = absolute URI

This seems about right.

> the ability for entries to exist independently of a feed.  For 
> instance, when using the Atom API to post a new entry, @profile on the 
> entry
> entry before that entry is ever made part of a feed.  If we are going 
> to allow entries to exist independently of a feed, @profile on entry 
> should be supported.

I agree that @profile should be allowable in an Atom Entry Document; 
what I wanted to avoid was the situation where an Atom Feed Document 
contains a feed-level @profile and conflicting entry-level @profiles.

I'll amend my proposal to make this clear; I think it's just making the 
placement similar to that of @version today.

> create new customized profiles with new unknown identifiers.

As I said, I'm not against multiple profiles, but this depends on #3...

> For #3, restricting profile to what elements are required while 
> keeping cardinality as part of the element definition does not seem 
> logical to me. Look at XML Schema as an example...
>
>   <xs:element name="foo"/>
>   <xs:element name="bar">
>     <xs:complexType>
>       <xs:sequence>
> element definition.  It wouldn't make any sense to do the following, 
> as each element that may choose to contain foo will specify whatever 

This is the one I feel most strongly about, but I'm willing to be 
talked around.

My thinking is that the cardinality of the metadata is tightly bound to 
both its definition and its implementation. For example, take 
atom:title; it's defined as "the title for the feed/entry"; it doesn't 
make sense to have more than one; if it does, it's because semantics 
have been added to it, and that means it should *really* be a 
different, new metadata element.

Likewise on the implementation side, aggregator vendors are going to 
implement to only look for one title; if someone comes along and 
profiles to allow five titles, what is the implementation going to do 
with that? They'll need to write a whole bunch of new code to deal with 
it, and it won't work (reliably) with existing implementations.

Pushing cardinality to metadata definitions also makes #2 much easier; 
now we don't have to worry about what happens when one profile says 
"exactly one" and another in the same feed says "three to five." If 
cardinality is in the profiles, we suddenly have to deal with resolving 
conflicts between them.

> stability and interoperability.

Sure, but they can have URIs designated in the relevant RFCs. Shoving 
two namespaces -- even syntactically distinct ones -- in the same place 
isn't good design to me; it requires special-case code, and is apt to 
cause confusion and problems.

> proposal.  Any proper treatment of profiles should at least touch on 
> the topic of compatibility with the "core" profile"  
> PaceProfileAttribute, for instance, strongly recommends that any new 
> profiles be created so that they are backwards compatible with the 
> core while acknowledging that incompatible profiles could be created.

I don't think this is a good idea; parts of the "core" won't make any 
sense for some applications. If we allow multiple profiles to be 
advertised, someone can *say* that they're compatible with both 
FooProfile and the Core.

>   The proposal also states that @profile is informational only and 
> does not impose any implementation requirements on the part of 
> implementors.  Things aren't so clear with PaceProfile.  Is the 
> @profile attribute normative? Are implementations *required* to 
> validate against the profile?  What should an implementor do if an 
> unknown profile is found?

I thought this was clear (keeping in mind this is pre-spec text);

> Atom Processors MAY change their behaviour based upon it, but are not 
> required to do so.

I'll beef this text up to be more explicit, along the lines above.

Thanks!

---

From: Graham <[email-masked]>
Date: Mon, 14 Feb 2005 04:04:24 +0000

On 14 Feb 2005, at 3:42 am, James M Snell wrote:

> The proposal also states that @profile is informational only and does 
> not impose any implementation requirements on the part of 

Yes. I can't see any consideration against people creating spurious new 
profiles, or even of when a new profile should be created. Totally 
unacceptable in this form.

Graham

---

From: James M Snell <[email-masked]>
Date: Sun, 13 Feb 2005 21:28:52 -0800

> Thanks! I'm feeling much better; still not 100%, but miles away from 

Definitely good to hear.

> placement similar to that of @version today.

Excellent.  The only remaining challenge with the PaceProfile approach 
in regards to the placement of @profile would be that restricting 
@profile to the document level means that feeds MUST contain a 
homogenous set of entries (all conforming to the same profile(s)).  For 
the majority of cases, I highly doubt this is a problem.  The edge cases 
(most aggregation scenarios) could find some way to deal with it.  I'm 
happy to compromise on that one.

> This is the one I feel most strongly about, but I'm willing to be talked 
> around.
> 
> have been added to it, and that means it should *really* be a different, 
> new metadata element.
> 

Point taken, but the same argument may not apply to other metadata 
elements.  Here's one possible compromise:  for certain specific core 
metadata elements that simply do not make sense to duplicate (e.g. 
title, updated, etc) expressly state that profiles cannot change their 
cardinality, but allow profiles to set the cardinality for elements for 
which no cardinality restrictions are defined.  Most of the core Atom 
metadata elements will have fixed cardinality, just as you're wanting. 
Yes, it does add a bit of complexity, but I definitely think it would 
allow us to meet both goals.

> cardinality is in the profiles, we suddenly have to deal with resolving 

Conflict resolution may not actually be that difficult (heh, famous last 
words) if "validation" of profiles is taken one at a time.  That is, if 
Profile A says "exactly one", Profile B says "three to five", and the 
entry contains one, the entry is conformant to Profile A and non 
conformant to Profile B.  With @profile being purely informational, it 
is up to the implementation to figure out what to do in such situations. 
  If we were defining @profile such that strict conformance were 
required, yes, it would be much more of a problem.  As it is tho, if a 
feed producer isn't going to be creating a feed that is conformant to 
Profile B, they shouldn't exactly be making any claims in @profile that 
Profile B is supported.

> cause confusion and problems.

By this argument, I assume you don't like the dual mechanism in @rel 
either?  (no challenge if so, I just don't know the background).  In any 
case, you make a valid argument.  The primary reason 
PaceProfileAttribute used the dual URI/IANA name approach was to 
maintain a consistent approach with @rel.  Limiting to URI is fine so 
long as a statement about how such URI's are defined and acknowledged as 
being "officially recognized" is added.

> advertised, someone can *say* that they're compatible with both 

Ok, but interoperability still needs to be given treatment in the spec.

> I thought this was clear (keeping in mind this is pre-spec text);

Of course, I might just have been being dense, but it wasn't clear when 
I first read over it.  I'll look at it again.

- James M Snell