W3C home > Mailing lists > Public > www-xkms@w3.org > October 2004

Re: A comment and some questions about the new schema

From: Rich Salz <rsalz@datapower.com>
Date: Fri, 15 Oct 2004 08:10:40 -0400 (EDT)
To: Tommy Lindberg <tommy.lindberg@gmail.com>
cc: "www-xkms@w3.org" <www-xkms@w3.org>
Message-ID: <Pine.LNX.4.44L0.0410150749001.4747-100000@smtp.datapower.com>

> 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.
Received on Friday, 15 October 2004 12:10:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:28 UTC