* David Powell <[EMAIL PROTECTED]> [2005-04-13 21:50]: > I agree that the Atom RFC shouldn't be a moving target. How > about if we: > > Make an IANA registry of Atom Text Types, requiring some > level of RFC to create new ones. > > Put text, html, and xhtml in the registry, and specify that > xhtml means XHTML1.0 > > Describe what processors should do if they encounter an Atom > Text Type that they don't understand.
This is what I first thought, too. Obviously, the last point of these points would be the most important, and extra care would have to be taken not to foul it up. But is this really a good idea? One aspect I donât like about this proposal is that it swaps a fairly important part of Atom out of the core spec and into a registry, which makes it harder for first-time implementors to pull together all the pieces required. Another aspect is that it seems that it would hurt interop: even if I know which version of the Atom spec is used by an upstream producer or expected by a downstream consumer, I canât know whether we agree on text types. If support for a set of text types is inextricably tied to support for a certain version of the Atom spec, then no ambiguities arise. A final aspect is that because this is so central to Atom, I donât know if it can be guaranteed that updates to the spec will not require updates in the registry or vice versa. Should that ever happen, registrations will suddenly have to track which Atom spec version they are for, or contain multiple definitions to be chosen from according to Atom version, or some other mechanism, any form of which will tie registrations and core spec versions to each other. That negates any gain ever had by separating the text types out of the core spec. All in all, I think creating registries is best avoided. Regards, -- Aristotle
