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

Re: schemaLocation

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Sun, 18 Mar 2007 10:09:43 -0000
Message-ID: <001301c76945$9f148310$5900a8c0@Codalogic>
To: "Mystra x64" <mystra_x64@fastmail.fm>
Cc: <xmlschema-dev@w3.org>

Mind you, XML already reserves any name starting with 'xml'.  So that got me 
to thinking you could do:

mycoolns:xmlSchemaLocation="http://someothercoolurl.com/file.xsd"

But then, it's the whole name that has to be xml prefixed, so you'd have to 
do something like:

xmlSchemaLocation:mycoolns="http://someothercoolurl.com/file.xsd"

This looks very xmlns use-case like, and has potential I guess.  However, I 
think the xmlns use-case is a bit of a fudge (or at best an exception) as 
normally a name is split into namespace prefix and local part.  Having some 
names being split one way and other names that are split other ways is a 
recipe for disaster in the long term.  (Especially if it opens the door to 
splitting names in other ways.)

If you can't mess with the attribute name, then that really leaves you with 
attribute value.  As there may be multiple schemas that define an XML 
instance, then you need to define multiple schema locations and with that, 
which of the schemas is actually associated with a particular location. 
Hence the list of pairs.  (See the example in 
http://www.w3.org/TR/xmlschema-1/#schema-loc)

XML has no mechanism for reserving all of the locally named attributes in a 
particular namespace, hence putting it into the XML instance namespace.

What would have been helpful I think is to either have predefined that 'xsi' 
is automatically known to all XML processors (without having to do an 
namespace declaration) or maybe even better, augment the xml namespace so 
that you could do:

 <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
            xmlns:html="http://www.w3.org/1999/xhtml"
            xml:schemaLocation="http://www.w3.org/1999/XSL/Transform
                                http://www.w3.org/1999/XSL/Transform.xsd
                                http://www.w3.org/1999/xhtml
                                http://www.w3.org/1999/xhtml.xsd">
and:
    xml:type
    xml:nil

etc.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================

----- Original Message ----- 
From: "George Cristian Bina" <george@oxygenxml.com>
To: "Mystra x64" <mystra_x64@fastmail.fm>
Cc: <xmlschema-dev@w3.org>
Sent: Sunday, March 18, 2007 7:54 AM
Subject: Re: schemaLocation


>
> Hi,
>
> One can think of many ways to do schema association, each have good points 
> and bad points.
> One bad point with your variant is that you reserve an infinite number of 
> attributes, one in each possible namespace.
> Anyway - the spec does not force you to use schema instance attributes, 
> the application that processes a document is free to take the schema from 
> wherever it wants so you can eventually implement your application to look 
> for schemaLocation attributes in different namespaces and use them to find 
> schemas - note that those schemas need to define also the schemaLocation 
> attribute.
>
> Regards,
> George
> ---------------------------------------------------------------------
> George Cristian Bina
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
>
> Mystra x64 wrote:
>> Hi,
>>  Why is schemaLocation is such a monstrous construct? I mean, let's say I
>> have
>> xmlns:mycoolns="http://url.com/ns". Then to specify a schema file I need
>> to write
>> xsi:schemaLocation="http://url.com/ns
>> http://someothercoolurl.com/file.xsd" and
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" to boot.
>>  Why not to use
>> mycoolns:schemaLocation="http://someothercoolurl.com/file.xsd" for that?
>>  i.e. any schema should have schemaLocation attribute in their namespace
>> regardless of definition.
>> Am I missing something?
>
> 
Received on Sunday, 18 March 2007 10:10:17 UTC

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