Re: XML Schema: DOs and DON'Ts

[Kohsuke KAWAGUCHI <kohsukekawaguchi@yahoo.com>]

Wow, thank you for your comments!  I'm glad to know that at least one
person has read my document.


> 1.    I'm curious as to how you would validate an element that had either
> attributes and/or element descendants without using complex types. I may
> have missed a major point here but I can't see how to validate;

Well, as you know, completely removing the word "complexType" from your
schema is impossible. What I wanted to say is one should use complexType
only under <element> element, and one should never declare complexType
globally.

So as for your example, I would suggest

<element name="person">
  <complexType>
    <group ref="person.contents"/>
    <attributeGroup ref="person.attributes"/>
  </complexType>
</element>


> without defining a complex type to describe the content of person. So, are
> you saying "don't use complex types" or are you saying "don't use named
> complex types"?

The latter is my intention. Don't use named complex types.



> 2.    Restriction gives you more that just error checking. You also get a
> type relationship between the base type and the derived type.

Well, that is true. We get type hierarchy from complex types. But I
wonder what do we get from type relationship. I appreciate if you would
teach me what do we get from them.

In the future, maybe we'll have tools to do something useful with those
relationships. But there is no such tool. And tools like relaxer reveal
that tools can be equally useful without explicit type hierarchy.


Also, complex types give us type substitutability, which I failed to
mention.



> 3.    At the end of the day model groups only actually get used when they
> are referenced as part of a complex type definition.

Umm, I couldn't understand your point.


> 4.    Regarding your comment about attribute groups, why not just use a
> local attribute declaration? That *is* what you get anyway despite the
> syntactic sugar that, it would seem, makes you think otherwise.

Because I want to declare common attributes once and reference them frequently.



> <foo:person xmlns:foo="http://best.practice.com">
>   <familyName> KAWAGUCHI </familyName>
>   <lastName> Kohsuke </lastName>
> </foo:person>
>
> is 'bad use of XML namespaces'. I have lots and lots of places where I use
> *exactly* that approach and it works very nicely for what I do. I don't
> think you can call this one way or the other. Neither approach is *wrong*,
> they're just different

I agree that there is no document that defines what is right and what is
wrong in XML namespaces. So I wrote what I believe.

I don't deny that my article contains some exaggerations :-)
But that statement about XML namespace is no exaggeration nor
simplification. It's my true feeling.

I know some people uses namespaces in that way, but I never really
understand why does this make sense. But I may miss the big point.

Again I'd appreciate if you would tell me why you wrote

<foo:person xmlns:foo="http://best.practice.com">
  <familyName> KAWAGUCHI </familyName>
  <lastName> Kohsuke </lastName>
</foo:person>

instead of 

<person xmlns="http://best.practice.com">
  <familyName> KAWAGUCHI </familyName>
  <lastName> Kohsuke </lastName>
</person>

And how you can put your fragment into *** of the following container?

<?xml version="1.0"?>
<root xmlns="uri:myMightyXMLContainer">
    ***
</root>


> 7.    Chameleon schemas. I don't feel strongly about this but another way of
> looking at the problem is this; use local declarations instead if global
> declarations.

Apparently there are many things you can't write without global
declarations. You can't use local declaration "instead of" global ones.
You can only use local ones along with global ones.

However, I also failed to mention that local elements give you a power
to reuse the same tag name. That's another truth.



> P.S. All your namespace URIs for schema have a type they should be
> http://www.w3.org/2001/XMLSchema *not* http://www.w3.org/2001/XMSchema (
> note missing 'L' character )

Oops! thank you.


regards,
----------------------
K.Kawaguchi
E-Mail: kohsukekawaguchi@yahoo.com