Subject: PaceProfile

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 14:20:54 -0700

+1.

I may have missed something, but I didn't see it specified whether one 
document could list more than one profile or not.  I think it should 
not be allowed.  With multiple profiles mixed, it would be more 
difficult to figure out exactly what to expect, and I don't expect it 
to be necessary--if you want to specify a feed that's a hybrid of two 
profiles, create another profile that describes exactly what you're 
after.

Profiles could take care of the job of specifying how to create what I 
recently referred to as Collection Documents and Archive Documents 
(identical except that multiple versions of a particular entry would be 
allowed in Archive Documents).  I would be fine with dropping 
PaceArchiveDocument, and allowing <content> and <summary> in head 
(PaceCommentFeeds--let's keep link/@rel="comments" though) if this is 
accepted.

Question: If head-in-entry were removed from the spec, could a profile 
indicate that <entry> could contain a <head> that specified the feed 
data relevant to the entry?  I'd be in favor of handling aggregation 
that way, and would support PaceAggregationInSeparateSpec, and would be 
happy to drop PaceAggregationDocument and PaceAggregationDocument2 if 
that were the case.

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 13:45:17 -0800

The specification of multiple profiles is one of the differences between 
PaceProfile and PaceProfileAttribute.  Mark's original proposal does not 
allow for multiple profiles, mine does.

Mark's Proposal:

* @profile or modified @version on the document level
* one profile per document
* profile applies to the entire document
* a profile describes what metadata elements are required and 
cardinality thereof

My Proposal:

* @profile on the <atom:feed /> and <atom:entry /> levels (independent 
of document arrangement)
* multiple profiles per <atom:feed /> <atom:entry />
* profile applies just to the <atom:feed /> or <atom:entry /> element 
upon which it appears.  it does not apply recursively down the structure.
* a profile describes what metadata elements are required and 
cardinality thereof
* profile is strictly informational and does not impose any operational 
requirements on the part of consumers/producers

Mine is admitedly more complex, but it also, in my opinion, provides 
greater flexibility.  Whether that greater flexibility is required is a 
separate question that is open for debate.

WRT multiple profiles, since all a profile is is a statement of which 
elements are required and the cardinality thereof, the union of the 
profile requirements is what is expected in the document.  For instance, 
if profileA requires <foo /> and profileB requires <bar />, processors 
should expect <foo /> and <bar />.  The only contention will be if 
profileA and profileB specify requirements for a different cardinality 
of some common element.  e.g. profileB requires no more than 1 <foo /> 
and profileA requires no fewer than 2 <foo />.  If the element contains 
2 <foo />, then the processor determines that the element is conformant 
with profileA, but not profileB.  It is up to the processor to figure 
out what to do in such cases. Alternatively, a rule can be specified 
that the profile with the highest cardinality for element <foo /> takes 
precedence.

For interoperability sake, the creation of profiles should have a 
somewhat high bar.  creating "another profile that describes exactly 
what you're after" should not be something done willy-nilly if you 
expect people to have a clue what they're producing/processing. 
Restricting profiles as we've done, composing multiple well-defined 
profiles on the fly will be more reliably interoperable than creating a 
brand new profile to fit some specific situation.

 > happy to drop PaceAggregationDocument and PaceAggregationDocument2 if

Yes, with either option (PaceProfile or PaceProfileAttribute).

- James M Snell

Antone Roundy wrote:
> document could list more than one profile or not.  I think it should not 
> be allowed.  With multiple profiles mixed, it would be more difficult to 
> figure out exactly what to expect, and I don't expect it to be 
> necessary--if you want to specify a feed that's a hybrid of two 
> profiles, create another profile that describes exactly what you're after.
>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 16:49:37 -0500

-1, I guess. This Pace proposes an organization of the spec which 
assumes we accept PaceProfileAttribute and/or keep the version 
attribute. I think the layout is reasonable for that scenario, but it 
overlaps with PaceExtensionConstruct and some others. I don't really see 
much reason to do a Pace for this. Perhaps it's meant to counter 
PaceOrderSpecAlphabetically.

I'm not really opposed to either Pace, but these are editorial issues, 
which the WG can address after the format is locked down. Right now, I 
feel they are just confusing matters. I think we should close them and 
deal with this problem around Feb 21ish[0].

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 14:07:56 -0800

Actually, PaceProfile was proposed prior to PaceProfileAttribute and is 
an independent proposal.  I offered PaceProfileAttribute as a separate 
proposal because 1) PaceProfile didn't really specify any specifics for 
the the @profile attribute beyond suggesting that it be created or that 
@version be modified and 2) I did not think that a complete 
restructuring of the document was really necessary.  I tried to be more 
specific in PaceProfileAttribute.  I am quite certain that Mark has his 
own ideas with regards to PaceProfile and that he would not agree that 
PaceProfile depends on PaceProfileAttribute in any way.  Likewise, 
PaceProfileAttribute has no dependencies on PaceProfile.

- James M Snell

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 17:22:39 -0500

James M Snell wrote:
> I am quite certain that Mark has his

Oh! This isn't editorial at all, then. I guess I'd have to see some more 
  spec text, then. I'm not sure what Mark is proposing.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 17:41:03 -0500

>  spec text, then. I'm not sure what Mark is proposing.

I missed that too... otherwise I would have simply put this Pace in the 
Recommended for Closure list.

-1 on this Pace until section 6 is flushed out.

- Sam Ruby

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Feb 2005 14:49:22 -0800

-1 because it is incomplete (no text for the new profiles in Section 
6). The specification of those profiles could have a major technical 
effect on the rest of the document.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 16:06:29 -0700

On Monday, February 7, 2005, at 03:41  PM, Sam Ruby wrote:
>>> own ideas with regards to PaceProfile and that he would not agree 
>>> that PaceProfile depends on PaceProfileAttribute in any way.  
>>> Likewise, PaceProfileAttribute has no dependencies on PaceProfile.
>> Oh! This isn't editorial at all, then. I guess I'd have to see some 
>> more  spec text, then. I'm not sure what Mark is proposing.
>
> I missed that too... otherwise I would have simply put this Pace in 
> the Recommended for Closure list.
>
Please finish it!  If it turns out close to the way I understand it 
from what's already there and the discussion thus far, it will keep my 
support.

---

From: Graham <[email-masked]>
Date: Mon, 7 Feb 2005 23:19:04 +0000

Profiles seem to be a way for people who disagree with decisions made 
by this working group to invent their own Atom format and claim it is 
valid Atom. No thank you.

-1

Graham

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 15:32:41 -0800

No, profiles are a way of folks to tweak the metadata containment 
requirements of feeds/entries for specific use cases (example: creating 
an archive as opposed to a syndicated feed).  While I cannot speak for 
PaceProfile which does not call out any specific text on the matter, 
with PaceProfileAttribute the production of new profiles that are 
backwards compatible with the core profile is STRONGLY recommended but 
not required.  PaceProfileAttribute assumes a community vetting process 
that optimistically assumes that a) creation of new profiles will be 
fairly rare and b) such profiles will only enjoy broad use if they are 
actually made interoperable with the core.  Folks that attempt to be 
incompatible with the core requirements would have to convince the other 
Atom software providers to support their profile if they wish to achieve 
any level of interoperability.

- James M Snell

Graham wrote:
> 
> Profiles seem to be a way for people who disagree with decisions made by 
> this working group to invent their own Atom format and claim it is valid 
> Atom. No thank you.
> 
> -1
> 
> Graham
> 
>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 18:44:42 -0500

>> valid Atom. No thank you.

I'm not sure they are that antagonistic, but I agree with Paul when he 
says they could be added later. If profiles aren't supposed to matter to 
"Core Atom" processors, why not put our money where our mouth is and 
make profiles declare themselves in their own namespace?

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 15:58:17 -0800

> make profiles declare themselves in their own namespace?

Suppose I want to require that a feed head MUST specify at least one 
category element for a specific type of use case. (just pulled the 
example from the air).  I want folks to be able to know that I'm using 
alternative containment requirements.  I want everything else to remain 
the same so that processors that aren't familiar with my modified 
profile can simply ignore it and process according to the core. Just so 
I understand exactly what you're thinking on this, how would I handle 
this using the extension approach?  Could you provide some strawman 
angle brackets?

- James M Snell

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 19:13:21 -0500

> this using the extension approach?  Could you provide some strawman 

So, you're looking for a way to include a "schema" association in the 
feed, and you want a standard way to do it. The only processors that 
will do anything useful with this information are those that know about 
the "profile".

<feed ...>
<head>
   <ex:MyPetSchema>GottaHaveCategories</ex:MyPetSchema>
</head>
...
</feed>

You're using Atom, and processors who know about your additional 
requirements will know about your schema. What you're asking is for the 
spec to lend weight to your extensions, and I'm not very positive about 
that.

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Mon, 07 Feb 2005 16:38:19 -0800

--On February 7, 2005 7:13:21 PM -0500 Robert Sayre <[email-masked]> wrote:
>
> So, you're looking for a way to include a "schema" association in the feed,
> and you want a standard way to do it. The only processors that will do anything
> useful with this information are those that know about the "profile".

Sounds like a job for <!DOCTYPE>.

Or a processing instruction, but I seem to be the only person that likes those.

wunder
--
Walter Underwood
Principal Architect, Verity

---

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

>   <ex:MyPetSchema>GottaHaveCategories</ex:MyPetSchema>

I don't see the value in this in that it opens up the possibility that 
every extension that wants to change the containment requirements could 
do so in some different way.  It doesn't provide any guidance on how to 
change those requirements in a backwards compatible way, nor does it 
help figure out how to reconcile a situation in which multiple such 
extensions are applied to the same feed/entry.  Further, the core spec 
still does not expressly allow extensions to change the containment 
requirements.  Thus far, the only thing an extension can do is add new 
types of namespace qualified metadata elements.

> spec to lend weight to your extensions, and I'm not very positive about 

No, what I'm asking for is a single, consistent way of declaring the use 
of profiles and the ability to make containment requirements independent 
of the element definitions.  The spec is not lending weight to anything 
but its own core profile.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 19:44:37 -0500

James M Snell wrote:

> Further, the core spec 
> requirements.  

That's right.

> Thus far, the only thing an extension can do is add new 

Yes.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 00:48:12 +0000

> spec to lend weight to your extensions, and I'm not very positive about 

The problem is that switching on the content of an element/attribute is 
Atom's get out of jail card wrt extensibility. It is the default Atom 
extensibility model, as it's the only game we have to play that doesn't 
involve screwing about with the meaning of existing core data items or 
adding new core items. Allowing people to add elements in other 
namespaces under atom:feed or atom:entry and calling that extensibility 
is like saying a new carpet in my living room is an extension to my 
house - it's a crashingly weak approach.

It seems to me then that if there's room for believing that there is a 
set of potential switches, there is room for discussing a core 
element/attribute to paste them into.

The same argument you make against @profile can be made about @rel. 
Indeed you could do all this profiling stuff with a new range of values 
and allowing @rel on the atom:feed element, or less obvious, into the 
atom:feed/atom:link[@rel] part. Either of which I think I'd prefer - as 
we only have extensibility approach it doesn't add value of 
comprehension to call its slot by two different names.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 00:59:25 +0000

Robert Sayre wrote:
> 
> James M Snell wrote:
> 
>> Further, the core spec still does not expressly allow extensions to 
>> change the containment requirements.  
> 
> That's right.

With good reason - as we have no processing model in place to explain 
how such extensions should be evaluated we have no business allowing them.

>> Thus far, the only thing an extension can do is add new types of 
>> namespace qualified metadata elements.
> 
> Yes.

This is not the case - we are using @rel to extend (scoped to links).

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 12:08:40 +1100

> make profiles declare themselves in their own namespace?

would it be acceptable to use a profile to weaken cardinality rules?

for example, a profile for a (S)SFF (remember them?) would allow entries as
minimal as this:

    <entry>
        <id>some-id</id>
        <link rel="self" type="application/atom+xml" href="..." />
        <updated>...</updated>
    </entry>

how might this be represented in a namespaced extension instead?

e.

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 17:37:58 -0800

With PaceProfileAttribute, weakening cardinality is possible with the 
strongly worded statement that new profiles SHOULD be defined so that 
they are backwards compatible with the core (thereby making weakened 
cardinality Not A Good Idea).  Also, I would argue that if multiple 
profiles are allowed and are applied, the profile with the highest 
cardinality takes precendence.  In other words, if someone declares that 
they are applying both the core profile and a profile that makes 
optional some element the core requires, the core takes precendence and 
the element is required.

- James M Snell

---

From: Graham <[email-masked]>
Date: Tue, 8 Feb 2005 02:28:58 +0000

>         <link rel="self" type="application/atom+xml" href="..." />

That's not an entry so it doesn't need to be an atom:entry:

<ssff:index>
  <atom:head>
    ...
  </atom:head>

  <ssff:reference>
      <atom:id>some-id</id>
      <atom:link rel="self" type="application/atom+xml" href="..." />
      <atom:updated>...</updated>
   </ssff:reference>

   ....

</ssff:index>

(In the general case, I'd like non-compatible profiles to use different 
top-level/collection elements)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 22:05:53 -0500

> house - it's a crashingly weak approach.

So, is that a +1 or a -1 on the profile concept?

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 12:47:51 +0000

Robert Sayre wrote:
> Bill de hÓra wrote:
> 
>>
>> The problem is that switching on the content of an element/attribute 
>> is Atom's get out of jail card wrt extensibility. It is the default 
>> Atom extensibility model, as it's the only game we have to play that 
>> doesn't involve screwing about with the meaning of existing core data 
>> items or adding new core items. Allowing people to add elements in 
>> other namespaces under atom:feed or atom:entry and calling that 
>> extensibility is like saying a new carpet in my living room is an 
>> extension to my house - it's a crashingly weak approach.
> 
> 

[You mean we have to decide?!?. Now!?!]

+1 on the concept. I've seen enough cases in the last week to suggest 
it's useful.

-1 on "@profile" - use an @rel to hold the content instead. I'm not sure 
whether atom:feed should get an @rel or whether we should use 
atom:feed/atom:link[@rel].

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Tue, 8 Feb 2005 09:01:31 -0700

On Tuesday, February 8, 2005, at 05:47  AM, Bill de hÓra wrote:
>>> doesn't involve screwing about with the meaning of existing core 
>>> data items or adding new core items. Allowing people to add elements 
>>> in other namespaces under atom:feed or atom:entry and calling that 
> -1 on "@profile" - use an @rel to hold the content instead. I'm not 
> sure whether atom:feed should get an @rel or whether we should use 
-1 to using naming it @rel.  <feed rel="core"> wouldn't make any sense 
at all--"The feed's relationship is 'core'."  Relationship to what?  
<feed>...<link rel="core" href="?????" /> likewise makes no sense--what 
are you going to put in @href?

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 16:16:41 +0000

Antone Roundy wrote:
> <feed>...<link rel="core" href="?????" /> likewise makes no sense--

That nicely sums up the feelings I have had about @rel. It's a bucket 
for putting switches into - the implied dispatching is the same whatever 
it's called.

Why can't @rel be short for @relevance?

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Wed, 9 Feb 2005 11:20:59 +0100

> +1 on the concept. I've seen enough cases in the last week to suggest

+1

> atom:feed/atom:link[@rel].

Not sure on this - the @profile name might act as a good hint to its purpose.

+0, looking forward to some refactoring of the proposals...

-- 

http://dannyayers.com