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 definition4. PaceProfileAttribute = Profiles are absolute URI's or IANA
registered names
PaceProfile = absolute URIOk, 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
Mark Nottingham wrote:
On Feb 13, 2005, at 2:03 AM, Anne van Kesteren wrote:
Mark Nottingham wrote:
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.
Do I understand it correctly that the profiles themselves still need to be discussed?
That's the purpose of this Pace. Are you asking something else?
Also, you can not mix profiles like you can in HTML 4.01? (Although there it is underdefined.)
That's my intention in this proposal. I'm amenable to allowing multiples, though, as mentioned in the notes.
I would also like to know what is meant exactly with metadata elements. Which elements does that include and which are excluded.
All of those that are children of atom:head and atom:entry are metadata.
-- Mark Nottingham http://www.mnot.net/
