Usage of hash sign in schema

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

In schema, several attributes have "special" values that start
with a hash sign, e.g. #all (for final) and ##any, ##targetNamespace,
##local (for namespace). What is the rational for having the hash
sign there? Wouldn't "all" have worked just as fine for fullDerivationSet?

Regards,
Martin

[Joseph Kesselman]

At a guess, without having checked: Reduce the risk a human will confuse
these with values which aren't keywords?

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

At a guess, without having checked: Reduce the risk a human will confuse

these with values which aren't keywords?

So no technical reasons. Could well be. However, for final/block, every
other possible value is a keyword, too (restriction, extension, ...) -
it's an enumerated type. So this human is rather confused by the
presence of the hash than by its absence :-)

Regards,
Martin

[Richard Tobin]

In article <47***********************@news.freenet.de>,
Martin v. Löwis <ma****@v.loewis.dewrote:

>In schema, several attributes have "special" values that start
with a hash sign, e.g. #all (for final) and ##any, ##targetNamespace,
##local (for namespace). What is the rational for having the hash
sign there? Wouldn't "all" have worked just as fine for fullDerivationSet?

I think the double hash is to prevent it from clashing with any
possible namespace name (though namespace names are supposed to be
absolute URIs).

-- Richard
--
:wq

[usenet]

On 8 Jan, 23:50, [e-mail] (Richard Tobin) wrote:

In article <4783dfd6$0$12460$[e-mail]>,
Martin v. Löwis <[e-mail]:

In schema, several attributes have "special" values that start
with a hash sign, e.g. #all (for final) and ##any, ##targetNamespace,
##local (for namespace). What is the rational for having the hash
sign there? Wouldn't "all" have worked just as fine for fullDerivationSet?

I think the double hash is to prevent it from clashing with any
possible namespace name (though namespace names are supposed to be
absolute URIs).

The double hash also makes sure it won't match any valid QName /
NCName. I'm not sure if this is significant for XSD 1.0, but it will
be for XSD 1.1 (where a wildcard can currently have a value of
notQName='##defined').

Whether this is by design, or a lucky break for the people developing
XSD 1.1 I don't know!

HTH,

Pete Cordell
Codalogic
Visit http://www.codalogic.com/lmx/ for XML C++ data binding