XSchema Spec, Section 3, Draft 1 (Namespaces)

[Simon St.Laurent]

>it doesn't make sense to
>require that a second mechanism duplicate (part of) the behaviour of the
>first.

Philosophically, XSchema's already a massive second mechanism.

>any processor which can read a document which follows the scahem spec
>will already have to be "namespace aware". it makes much more sense to 
>require of the first mechanism, that it offer an (additional) interface 
>function of the form
>  (document X qualified-name ) -> symbol.
>yes, this is missing in the present namespace proposal. which is reason to 
>fix it (given that it's still in flux), not reason to do something else.

As I said before, this is one option.  I don't think the namespace proposal 
adds anything to our processing of the XSchema at this point which the 
namespace element doesn't do better.  I don't see XSchemas needing to 
including both the namespace declaration for XSC-whatever and the declarations 
for the instance elements; this separates the NS declaration for the XSchema 
itself from the namespace declarations of documents-to-be-processed quite 
neatly and adds extra functionality (documentation, etc.) that I think is 
needed to make namespaces friendlier.

>for documentary purposes, or to bind a schema to the ns identifier if/once 
>the src attribute gets dropped from the namespace pi, a namespace declaration 

>for xschema makes perfect sense.

Precisely.

>an encoding which requires that information appear redundantly makes sense
>only in the face of noise or some other potential for misinterpretation.
>that's not the problem here.

Yes, the information will have to appear in the namespace declaration of the 
document and in the namespace element of the XSchema used to define it.  The 
issue isn't noise; the issue is independence from a painful search-and-replace 
should the document or the XSchema owner change the prefix.  The information 
will need to appear in both the document and the XSchema in one form or 
another.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)