Tuesday, August 16, 2005, 8:00:55 PM, Mark Nottingham wrote:
> I very much disagree; relative references should be allowable in > simple extensions, and in fact the rationale that Tim gives is the > reasoning I assumed regarding Atom extensions; if I had known that > the division between simple and complex extensions would be used to > justify a constraint on the use of context in simple extensions, I > would have objected to it. The constraint on the context is the main reason for the distinction between Simple and Structured extensions. Why else would we define two classes of extension if it didn't affect the processing model, and why else would we make Simple extensions language-insensitive (a very similar constraint on context, which is spelt out quite clearly, and therefore presumably not disputed)? > If you're using something like RDF to model feeds, you already have a > number of context-related issues to work through, this isn't an extra > burden. Yeah a few, Structured extensions are obviously a big one (where the lang and base context do need to be preserved). The reason for there being two classes of extensions was to reduce this burden, so that implementations based on RDBMS, RDF, or whatever can process a common class of unknown extensions generically. The burden of requiring the lang and base context to be preserved in a legacy CMS database along with each extension, on the off-chance that they might be significant seemed to great. If you think that the context shouldn't be constrained, then maybe you're right - maybe the constraint was unnecessary; but I think that the current spec does impose that constraint, albeit too subtly, in Section 6.4.1 paragraph 2, and that constraint is what I originally intended. If a significant number of people have not picked up on this (the lack of rationale probably didn't help), and would have disputed it, then I guess that we have a problem. -- Dave
