RE: Enumerations in schema

I guess I don't care about XML esoterica like this but I do
care about:

  - we are correct to disallow the (eqsy/obvious) addition of
    an N-R bit here, and this is a real issue since I have in
    the past been asked to do just that
  - if a change affects how long it takes to finish the work here in
    terms of W3C process or, more importantly, coding/testing

Modulo those things, make whatever changes the XML-heads
recommend (though I do have to say I kind-of know what a URI is,
and have no idea what a QName is supposed to be so...)

Stephen.

PS: I'm in the middle of travel/vacation so won't be able to
respond quickly/often until the 20th.

>> 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 11:08:02 UTC