We also don't have a way to explain which of the tightly controlled list
the server supports for metadata retrieval.
So I'm with Mike on this one (yes, a flipflop, in the US political sense
rather than the antipodean footwear sense).
I'm also in favor of the language neutral '1' as the value.
I haven't written the schema up, but will get to it ASAP.
Rob
On Thu, 2007-05-03 at 14:09 +0100, Mike Taylor wrote:
> 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
> it.
>
> > Your approach would be to name a well known schema?
>
> Yes.
>
> > 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
> recordSchema=someOtherSchema
>
> > We define a new extension, similar to this one, for that schema.
>
> No.
>
> > 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.
|