Let's try this:

The "well-known" schema (let's say it's 'rec', for discussion sake) would be
mandatory, that is, a client who claims to implement the extension must
accept 'rec', no matter what it requests, and a server must support 'rec',
no matter what else it supports.

So lets say the controlled list consist of:  'rec', 'any', 'dc', 'rec2'

So the parameter must be one of:

x-info-99-metadata=rec
x-info-99-metadata=any
x-info-99-metadata=dc
x-info-99-metadata=rec2

In the first case, the server has to use 'rec'.
In the second case, it could be 'rec', 'dc', or 'rec2'
In the third case, it could be 'rec' or 'dc'
In the fourth case, it could be 'rec' or 'rec2'

I don't see how this could pose an interoperability problem, and I don't
think there is a need to "explain' which are supported.

--Ray


----- Original Message ----- 
From: "Rob Sanderson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, April 17, 2007 7:50 AM
Subject: Re: Record Metadata Schema (was Re: "collection" context set)


> On Tue, 2007-04-17 at 10:08 +0100, Mike Taylor wrote:
> > Rob Sanderson writes:
> >  > Then we need to define a very thorough schema, or we'll constantly
> >  > be fielding requests: Can you just add <insert favourite metadata
> >  > field> please?
> >
> > Yes; but that's not the end of the world.  We already do this for the
> > various context sets, and in fact it's not a common or demanding
> > process.
>
> True.
>
> > Or we can explicitly allow the metadata schema to include extension
> > elements from other namespaces.
>
> I'd prefer this to be possible.
> Also agree on the interoperability point, to a certain extent.
>
> I'll try and convert rec1.1 context set into a schema later today for
> perusal, as the current rec 1.0 based schema is awful.
>
> Rob