OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Schema: DOs and DON'Ts

> > My motivation is to convince readers to use XML Schema as "DTD+NS+DT",
> > as I wrote in the introduction.
> But when XML Schemas was initially being developed, there was a clear view
> (rightly or wrongly) from the people calling for a schema language that the
> structures available in DTDs were not good enough.  If it were, then Simon's
> DTD-in-XML language would have been more acclaimed.

I don't want to say that DTD+NS+DT is enough; it's just that we shouldn't
expect XML Schema to give us more than DTD+NS+DT.

> Several of the comments (e.g. substitution groups, perhaps complex types)
> seem to be based on the argument that there should never be two ways to get
> the same
> result. But there is no reason to suppose that argument to be in general
> true, unless you are a minimalist 

Mmm, maybe partly because I'm a kind of the minimalist...

> I think it is
> enough to say that restriction or extension of content models provides
> unproven and minimal benefit compared to its complexity

I think what I wanted to say is about the "minimal benefit compared to
its complexity", although there is no way to understand my sentences in
this way.

"There is always another way that doesn't use complex types" should be
mentioned as one of the reasons that complex types have not much benefit.

> The reason I think Kawaguchi's particular argument "The latter looks like a
> restriction of the former" is weak, is because it will only "look" that way
> if someone has not gotten the key concept of type restriction in their head:
> this is found in section in the Structures document, and says
> something like "If every instance of type A is also valid against type B,
> then type A is a subtype of type B".  You always need conceptual knowledge
> to be able to read any markup language.

Oh, it is a terrible, awful mistake. I think you would be satisfied if I
modify the example to the following:

Base type (B):
> <xs:all>
>   <xs:element name="a" />
>   <xs:element name="b" />
>   <xs:element name="c" minOccurs="0" />
> </xs:all>

Derived type (D):
> <xs:all>
>   <xs:element name="b" />
>   <xs:element name="a" />
> </xs:all>

As you see, now every instance of the type D is also valid against the type
B. And D is still an illegal derivation from the type B.

So if you have the general concept only and doesn't have any specific
details of the derivation-by-restriction, then you would probably think
this is a valid restriction, which was my intention.

My reasoning was

- when it comes to the derivation-by-restriction, the general
  understanding is not enough. You need to learn many specific details
  of the derivation by restriction.

- so compared to its merit, it doesn't worth learning.

E-Mail: kohsukekawaguchi@yahoo.com