OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Key/keyRef scope


To resolve this issue, I propose that the key/keyRef symbol space would be
identified by a namespaceURI/local-name pair rather than merely by a
local-name. Syntactically, the value of the key and keyRef attribute would
be a QName rather than a NCName.  An NCName would be expanded using the
inherited value of the ns attribute, in the same way as the name attribute
of <element>.

If people cannot stomach any more use of QNames, then alternatively the
syntax could be left as it is, with key/keyRef taking an NCName: the
namespace URI of the symbol space would then always be identified by the
inherited value of the ns attribute.  However, this is not my preferred
option, since it prevents the symbol spaces of key and keyRef having
different namespace URIs and also makes it harder for one namespace to refer
to keys in another namespace.

This proposal would make it easy to avoid unintentional conflicts between
grammars for different namespaces with respect to keys, whilst still
allowing one grammar to refer to the keys defined by another grammar. It
adds no additional syntactic complexity.  At the moment all names that are
not scoped to a particular grammar can be namespace qualified with the
exception of key/keyRef; this proposal would remove this exception.

James




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC