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

RE: Enumerations in schema

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 7 Jul 2004 06:20:36 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BE8F0@mou1wnexm05.vcorp.ad.vrsn.com>
To: "'Berin Lautenbach'" <berin@wingsofhermes.org>, Rich Salz <rsalz@datapower.com>
Cc: www-xkms@w3.org

> OK - I'm confused. :>.

Me too.

The whole QName thing looks like it was a mistake. The problem is 
that it is a feature of XML Schema that did not get thought out half
as well as it should at the time.

I beleive that the spec is correct as currently specified, but 
Qnames are a schema feature that need to be depricated so it
would be useful to move to URIs if that is viable.

Another approach that could be taken would be to simply remove the
enumeration in this particular case. I doubt that anyone is going
to attempt to create a 'nonRepudiation' use which was the purpose
of enumerating here (see PKIX for why :-)

In fact given that the enumeration is not extensible (by design)
there is really no reason to use URIs or QNames at all.

The big problem is that if you look at XML syntax there are really
two parts, the tags part and the values part. Namespace prefixes are
really something that belongs in the tags part. The reuse of the
QName component as value was a kewl hack but it caused the prefix
use to cross the line from the tags part to the data part.

This crossing of the separation between tagging and values caused
endless confusion for XML Signature - unfortunately after the XKMS
spec had been written.

What is really needed here is a better syntax for expressing prefixed
values that pulls the prefix back out to the tags part where it belongs.

> But to paraphrase what you say below, and how I understand what I've 
> just re-read in the schema spec.....  For normal QNames, this 
> should not 
> be a problem as the value space is the set of {URI,local 
> part} tuples. 
> I.e. prefix is translated to URI to give value space.  For 
> enumerations, 
> the problem is that the enumeration has to give the "actual value", 
> which is reprented as a string, which leads to a problem.
> Do I have that right?  Or have I just made it even less clear than it 
> was ? :>.
> Leading from that, I have two questions :
> Firstly - do we agree there is a problem?  (I believe there is, both 
> based on my understanding and your information below, but 
> Tommy I think 
> believes not?)
> Secondly - If the answer to 1 is yes, do we need to actually 
> define the 
> values in the schema at all?  Can we leave it as a QName and 
> define the 
> allowed values in the spec?
> Cheers,
> 	Berin
> Rich Salz wrote:
> >>>I'm not a huge expert in XMLSchema, but my understanding is that
> >>>enumeration values are literal.
> >>
> > 
> > When I said you were right, I was wrong.  In fact, you are wrong. :)
> > Sorry for the confusion (but hey, it's XML Schema, 
> confusion is standard).
> > 
> > The XSD "enumeration" element specifies a restriction on the *value
> > space*,  not the *lexical space.*  This means that yes, it shouldn't
> > match the exact string literal "xkms:Signature".  Unfortunately, the
> > way you specify the (err..) value-space value is to uses the lexical
> > space syntax.  For most things like strings, numbers, etc., 
> this isn't
> > a problem, for since QName's are a tuple (ns,localname) you have to
> > use the nsprefix:localname syntax.... ugh.
> > 
> > I got that from sections 3.2.18 and 4.3.5 of part 2 of the Schema
> > recommendation.
> > 
> > Let's move to URI's. :)
> > 	/r$
> > 
> > --
> > Rich Salz                  Chief Security Architect
> > DataPower Technology       http://www.datapower.com
> > XS40 XML Security Gateway  
> http://www.datapower.com/products/xs40.html
> > XML Security Overview      
> http://www.datapower.com/xmldev/xmlsecurity.html
> > 
> > 
> > 
> > 
Received on Wednesday, 7 July 2004 09:20:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:42 UTC