Re: A comment and some questions about the new schema

Thanks for that Rich.  

> One nice feature is that an
> application can just globally remove "OpoenEnum" from the type attributes,
> and get a strictly conforming, no extensions, schema.

Yes, I did something like this to validate the new spec samples.

Regards
Tommy

On Fri, 15 Oct 2004 08:10:40 -0400 (EDT), Rich Salz <rsalz@datapower.com> wrote:
> > I like the additional use of enumerations in the new schema, but am
> > dubious about the use of the *OpenEnum's.  Doesn't the various union's
> > undo all the specificity established through the enumerated extension
> > (by restriction) of anyURI?  If this is the intention, why enumerate
> > at all?
> >
> > Extensibility is mentioned in the context; is this the way to provide
> > extensibility and is the extensibility required?  Once the spec takes
> > recommendation status, wouldn't an extension of the value space of an
> > enumeration typically entail issuing a new schema with a new
> > namespace?
> 
> Excellent issues.
> 
> There are some places where the schema is extensible, such as the
> RespondWith element.  Is there any reason why an independant application
> can't add a new kind of data?  To make up an example, suppose someone
> wanted to return the subject key identifier, and defined a URI like
> http://www.example.com/xkms#ski .  Their applications can ask for it,
> their servers can return it, and it should all still interoperate and be
> schema compliant.  (The app would have to know what to do if a "standard"
> XKMS server faulted or didn't return the data, of course.)
> 
> There are some places where the schema is not extensible.  In particular,
> there's a requirement that KeyUsage cannot be extended (so that folks
> can't add NonRepudiation:).
> 
> Deciding where to allow extension, and where to disallow it, is one of the
> harder parts of writing a schema.  My view is that we now have it pretty
> much "the right way."  Of course, we can look at the extensibility points
> -- they're pretty obvious -- and revisit each of those decisions.  Your
> note raises this.
> 
> The second matter -- using the open enum technique -- is a separate one.
> It seems like the best way to allow forward compatibility.  The schema
> defines the syntax, and the spec defines the semantics.  The open enum
> method is the only way we have in schema to say "all values are allowed,
> but these are more equal than others" :)  One nice feature is that an
> application can just globally remove "OpoenEnum" from the type attributes,
> and get a strictly conforming, no extensions, schema.  The application can
> use that modified scheme for its own implementation.
> 
> Hope this helps.
>         /r$
> 
>

Received on Friday, 15 October 2004 13:40:07 UTC