«

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

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

> 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

In article <4783dfd6$0$12460$>,
Martin v. Löwis <> wrote:
>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

On 8 Jan, 23:50, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <4783dfd6$0$12460$9b622...@news.freenet.de>,
> Martin v. Löwis <mar...@v.loewis.de> wrote:
>
> >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