[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: QNames
> I am not sure if RELAX NG will always support QName. If I make a subset of > XML Schema Part 2, I will definitely get rid of QName as well as datatypes for > date and time. Also, different libraries (e.g., datatype libraries by > David RR Webber) will be in use. Even if there are datatype libraries that don't support QName, still the spec needs to support XML Schema Part 2, which means that the spec has to deal with in-scope namespaces. Also I expect/hope that implementations of RELAX NG will allow different datatyping implementations to be plugged in, rather than being tied to any single datatyping implementation. I would be surprised if any RELAX NG implementation did not provide interfaces sufficient to allow an implementation of XML Schema Part 2 to be plugged in. The net result is that I believe in practice RELAX NG implementations will have to support in-scope namespaces. Also in general programs manipulating RELAX NG schemas will need to deal with in-scope namespaces. If a RELAX NG schema restricts itself to a datatyping library that doesn't support QNames, then admittedly it can be manipulated without regard to in-scope namespaces. But allowing QNames for element and attribute names in a RELAX NG schema doesn't make things any worse: if a user wishes for some reason that their schemas be capable of being manipulated without worrying about in-scope namespaces, then it is already possible for them to avoid QNames and instead use explicit namespace attributes, just as they can, if they so choose, avoid using the QName datatype. The reality of the XML world today is that XML tools have to deal with in-scope namespaces. There are too many important languages that use them, notably XSLT and XML Schema. Admittedly, in-scope namespaces complicate processing. But other tools and standards already have to deal with this; for example, XML canonicalization already deals with in-scope namespaces. And the standard XML tools do deal with in-scope namespaces: SAX and DOM both fully support them. Thus, even if you think using in-scope namespaces is a terrible idea, there is no practical advantage, with the XML world as it is today, in eschewing reliance on in-scope namespaces. RELAX NG users would still have to pay the cost of in-scope namespaces in terms of increased tool complexity, because they are so widely used elsewhere, yet they would not get the benefit of increased convenience and ease-of-use to compensate for that cost. > 1. Always spell out the URI or use inheritanace of the ns attribute > > Yes, this is verbose and error-prone. But this works in some cases: > > Case 1: we use namespaces rarely > Case 2: inheritance of the ns attribute is good enough > Case 3: we will later introduce a mechanism like RELAX Namespace, That's certainly simple and coherent. On the other hand, it will make RELAX NG very cumbersome for declaring patterns that mix namespaces. Instead of <attribute name="xml:space"> <choice> <value>default</value> <value>ignore</value> </choice> </attribute> users would be forced to write <attribute name="space" namespace="http://www.w3.org/XML/1998/namespace"> <choice> <value>default</value> <value>ignore</value> </choice> </attribute> I cannot see that this is an improvement. > 3. The proxy attribute > > 1) Namespace declarations > > A grammar element begins with namespace delclarations (for the lack of a better name). > A namespace declaration declares a namespace URI and attaches a proxy to it. > > E.g., > > <grammar> > <namespace name="http://www.example.com" nsproxy="e"/> Then the order of the children of a <grammar> element becomes significant. And how do I declare namespaces if I am not using a <grammar>? And what about <value>s of type QName? With this proposal, there would seem to be two choices, both unattractive: (1) the prefix is expanded using the namespaces declared by namespace declarations; this means the user has to deal with two different ways of declaring bindings between NCNames and namespace URIs (2) the prefix is expanded using the bindings declared by <namespace> elements; this means that <value>s of type QName are confusingly differently in the schema and in the instance The proxy attribute seems to me even worse than the option of spelling namespace URIs out explicitly. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC