W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2004

Re: qualified local/global Re: Namespace problem

From: Volker Zink <Volker.Zink@porabo.ch>
Date: Mon, 23 Aug 2004 12:10:44 +0200
Message-ID: <4129C2A4.7060504@porabo.ch>
To: Michael Kay <mhk@mhk.me.uk>
CC: xmlschema-dev@w3.org
I really would like to see a scenario, where this expressive power of 
the XML namespaces makes sense. But if we discuss this generally, there 
are many things to consider. First of all if i design something i.e. a 
language or an application (which i am more used to) i not only want to 
make it as powerful as possible (why design HTML or XML if you have 
SGML?), but i have an intent, a goal to achieve. My experience is, the 
design should be as small and easy to understand as possible to achieve 
this goal. But it should be flexible and easy to extend too (in the 
first approach you don't think of all possibilities).

IMHO the namespace design in XML is too powerful and therefore too 
complex. This means too hard to understand, too many errors when using 
it, too hard to implement. Namespaces are nothing new. Why are the 
namespaces in XML more powerful as their counterparts in the programming 
languages? There must be more than 'why not'.

Volker Zink

Michael Kay wrote:

>>You misunderstood me. To define a complex type and want 
>>element A to be 
>>of type X1 FROM namespace N1 and element B to be of type X2 FROM 
>>namespace N2 is not questioned by me. But why somebody want 
>>to define a 
>>complex type to be IN namespace N1 and an element of this 
>>type to be IN 
>>namespace N2? (Thats the case if you define a target namespace in the 
>>schema and miss the elementFormDefault)
>I think one should put the question the other way around. Why should the
>language disallow such a combination? Generally, a language should allow
>everything that makes sense (=has well-defined semantics), it should not
>disallow things merely because they don't appear to be useful.
>Michael Kay

Received on Monday, 23 August 2004 10:12:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:06 UTC