On Feb 13, 2005, at 7:42 PM, James M Snell wrote:
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.
Thanks! I'm feeling much better; still not 100%, but miles away from where I was last week.
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
This seems about right.
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.
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.
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.
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> <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.
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.
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.
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.
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.
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!
-- Mark Nottingham http://www.mnot.net/
