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.
> 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.
Yes, with either option (PaceProfile or PaceProfileAttribute).
- James M Snell
Antone Roundy wrote:
+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.
