Ray Denenberg writes:
> From: Mike Taylor
> >It sounds the same as it did the last time we went round this subject
> Not really. In fact not at all. Then, we were talking about
> allowing an arbitrary schema id. Here were talking about a
> controlled list (tightly controlled).
That is a fine distinction. The issue is the same: either we pick one
schema (in the knowledge that a client or server implementing that one
will be able to interoperate with any server or client that implements
the extension) or we allow a choice (with all the mismatching that
implies). To me, this is a no-brainer, but if anyone has a good
reason why they want to be able to choose which of several candidate
metadata schemas their server should support, I am ready to hear about
> Your approach would be to name a well known schema?
> What would that be, Rec?
Yes. (Does that exist yet? If not, mybe Rob could make it, based on
the elements in the corresponding context set.)
> So what happens the first time someone asks for the capability to
> do this by some other schema?
They can already request that as a primary record using
> We define a new extension, similar to this one, for that schema.
> That's not good for interoperability either.
That's why we don't do it.
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Always avoid and eschew pleonastic redundancy" -- Unattributed,
on TFTD mailing list.