Mark Nottingham wrote:
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.
Definitely good to hear.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ok, but interoperability still needs to be given treatment in the spec.
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);
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
