Re: XML Schemas: Best Practices

[Kohsuke KAWAGUCHI <kohsuke.kawaguchi@eng.sun.com>]

> If a schema validator ignores schemaLocation (or, as in the case above,
> there is no schemaLocation) then the validator is expected to "locate"
> the appropriate schemas by some other means.   Obviously, if the
> validator is unable to locate the appropriate schema then it will fail. 

My point is that you shouldn't drive validators to their limits in case
of XML Schema, especially under the name of "the Best Practice".

Consider this. You write a schema and one day you'll find that your
schema is no longer usable under your new validator.
I'm saying that your technique (I still think it's a trick) will cause
troubles like this.

It seems to me that you know that one validator accepts your schema, but
another may reject it; this is exactly what I meant by an interoperability
problem.



And technically, I think your explanation is still wrong. A validator
has no obligation to locate that schema by the other means. Nor it need
to fail the validation. I believe its sole obligation is to report a
proper "signal" when that component is actually used.



> This is true regardless of whether you're using dangling types or not. 

Exactly. So I think the best practice should be

"do not use include/import without schemaLocation attributes."

because it's the best way to avoid possible pitfalls.



> pattern, and it is the only way to do many things, e.g., it is the only
> way to extend a simpleType.  I think that this design pattern will be
> used heavily by schema designers.  In my work we use it a lot.

Well I don't know if it's the only way to do. Maybe so, maybe not. But
again, my point is that you should recognize this situation as
"extending a simpleType is a risky thing."

So we should rather think that such a thing("extending a simpleType")
should be avoided as much as possible. Instead, you should look for how
to modify your schema so that you don't need to extend simpleTypes.

Of course, if you are a schema expert (and I know you are) and you know
exactly what you are doing, then that is fine. It's your life.  But for
average schema authors, which are the target of the best practice text,
these tricks are too dangerous.



> You are correct that "before"
> namespace-coercion occurs the default namespace is the no-namespace. 
> However, after an <include> the components are no longer in
> no-namespace, they are in the targetNamespace of the <include>ing
> schema.  Hope this clears things up.  

You are right, but I think you don't oppose my argument.


Correct me if my terminology is wrong.

The default namespace is a namespace which is declared by xmlns="..."
attribute. So as you see, this is the concept of XML namespace.
QName is also a concept of XML namespace.

And the resolution of QName to (URI,local) pair is also a concept of XML
namespace. How QName is resolved to (URI,local) pair is nothing to do
with XML Schema. It's a rule that XML namespace calls for.


>    <xsd:element name="Book" type="CardCatalogueEntry"/>

My point is that

1. the above "CardCatalogueEntry" is resolved to
   the pair of (no-ns,"CardCatalogueEntry") where the author expects it
   to resolve to ("brabra","CardCatalogueEntry").

2. The above resolution does not matter who include the schema.

3. So, any schema that includes the above statement will not work as the
   author expects.



> Hmm, you seem to have a different copy than I have.  I just looked at
> the web site and it defines the camera schema as:

Oops, I'm sorry. Actually, I couldn't find the definition of Nikon.xsd,
Olympus.xsd, and etc. So I guessed it from your two samples.

Would you tell me where I can find the actual definition of three files?




> For this issue we don't dictate a "Best Practice".  Rather, we point out
> the pros and cons of each approach.  Each approach has scenarios for
> which it is preferred, as we describe in the online document.  

But the third bullet ("when you need the flexibility of being able to
change the schema without ....") is still wrong. This is an advantage of
"exposing namespace", not of "hiding namespace"



> No, they don't have the same semantics (assuming targetNamespace
> provides a level of semantics to components within it).  The whole point
> is that Chameleon components can have multiple semantics.  That's the
> power of Chameleon components!

OK. Then I would rather say that the chameleon schemas are useless
because you can't refer to a declaration in a chameleon schema from the
same schema.

I'd really appreciate if you would point me out what sections of the
spec makes you believe that chameleon schema works.


--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@eng.sun.com