* Smylers <[EMAIL PROTECTED]> [2007-03-02 22:55]: > A. Pagaltzis writes: > > * Smylers <[EMAIL PROTECTED]> [2007-03-01 21:45]: > > > Can't we just start using cc-author as a field, then if it > > > takes off get it blessed as part of the official spec? > > > > Then how do you tell whether `bastract` is a typo or > > extension field? > > You can't. But equally you can't tell if "hints: > test-reporter: cc_arthur" is a typo or not. (Admittedly if > it's a typo for "abstract" then it's a particularly _bad_ typo > ...)
Yes, you can’t know anything about extension elements. That’s a given. But if you contain them in an extension hook and disallow arbitrary placement of extension elements, then you can at least validate the rest of the document with strict rules. > > I think adding a `hints` field which is a hash of hashes, > > where the key in `hints` acts as a namespace, is the best > > proposition so far. > > The extra name-spaces avoid clashes. > > But I still think that the 'hints' level is unnecessary: for > any key in 'hints', can you imagine a situation where it's > _also_ a key top-level key? Think how confusing it would be to > have both 'test-reporter' and 'hints: test-reporter'. I’m not sure this would be particularly common problem? The point of `hints` is simply to contain extensions such that every part of the document other than what’s under `hints` is precisely specified. If you hoist the extension namespaces up one level, that is no longer the case: you don’t know if `bastract` is a namespace or a typo. (Same problem as with simply putting extension elements anyplace.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
