W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2007

Re: schemaLocation

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 19 Mar 2007 16:55:36 -0400
To: "Mystra x64" <mystra_x64@fastmail.fm>
Cc: "George Cristian Bina" <george@oxygenxml.com>, xmlschema-dev@w3.org
Message-ID: <OFA3BD4057.FCE7566D-ON852572A3.0072272C-852572A3.0072DC63@lotus.com>

Mystra x64 writes:

> Sure, that reserves an attribute for all schemas, but for me it
> sounds both kind of easier to implement and visually more appealing

That may be, but it's really contrary to the spirit of namespaces.  In 
fact, the whole point of namespaces is that other organizations >can't< 
mess with the names in the spaces you own.  Consider a vocabularly like 
xhtml.  It's the XHTML workgroup's responsibility to figure out what 
xhtml:schemaLocation is used for, if it's used for anything at all.  In 
fact, although it's unlikely with a clunky name like schemaLocation, in 
principle some namespaces could already have conflicting uses for that 
localName.  Poaching on other peoples' namespaces is just not OK.

> But the list of pairs in an attribute is kind of... well, ugly -

Indeed.  Honestly, I think the right answers are not allowed by XML, 
because it does not have structured attributes.  Consider what would be 
much better markup, in my opinion:


Good markup, clean, well typed, easy to process with XSL, etc. 
Unfortunately, you really do want schemaLocation to be an attribute, not 
part of the document content.  So, I claim, the real problem is that XML 
doesn't allow structured attributes:  all attributes must have simple 
type.  Once you're stuck with that, there really aren't good answers, IMO. 
 FWIW:  the reasoning in the schema WG, as I recall, was that we could at 
least use a list of URI type to get typing for the string. 

In any case, poaching on namespaces other than xsi or other ones we "own" 
is really not OK.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Monday, 19 March 2007 21:01:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:41 UTC