Well said, Paul; this articulates the reasons for a profiling mechanism much more effectively than I ever did.
Cheers,
On Apr 27, 2005, at 9:28 AM, Paul Hoffman wrote:
A few brief notes for the WG to chew on.
- Literal interpretation of 2119 for a document format such as Atom would make nearly every element of an entry a MAY. It is a tad dishonest to say "why is element Xyz even a SHOULD?" when we have a *long* list of MUSTs already. It is no wonder that people are changing their opinion of any particular element from MUST to MAY to SHOULD and around again.
- The format document, like many IETF Applications Area specs, is steeped in hidden semantics. If I suggested that atom:title go from MUST to MAY, there would be outrage. The reason is that most of us think of entries as having some semantics that include a title. We don't say in the format document why we made atom:title a MUST: it's just "obvious".
- Differentiating the importance of the semantics of various elements is really, really hard, and people's opinions change over time. I strongly suspect that many of the less-vocal-but-still-active members of this list have changed their view of the importance of atom:category at least once. This is the hardest one to align with making a simple-to implement spec. The fewer cross-element links we have, the easier it will be for an implementer.
- We have, unfortunately, linked the semantics of two or more elements together. atom:content and atom:summary are linked because of their semantics (if you don't have a readable content, you MUST/SHOULD/MAY have a summary).
- We have, fortunately, not required linked semantics for extensions. If I came out with hoffman:content-plus-plus, I can't assume that whatever linkage there is between atom:summary and atom:content will apply to my extension. But, of course, if someone considers hoffman:content-plus-plus to be like atom:content, they may *want* the same linkages.
- Every SHOULD, by definition, adds logic into the software that creates a message in the spec'd format. In the long history of the IETF, this also tends to prevent interop, because it gives two differing parties a soapbox to argue from.
- Person A may think that an optional element that is missing means W. Person B may think that an optional element that is present but null means X. Person C may think that W == X, Person D may think that W != X. Person C and Person D will probably code very differently.
Proposal for thinking about: to simplify the spec, "atom:summary" should either be a MUST in all cases or a MAY in all cases. If it is just semantic like "atom:category", it should be a MAY. If it is inherently valuable like "atom:title", it should be a MUST.
--Paul Hoffman, Director --Internet Mail Consortium
-- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
