Re: Schema subset efforts

> Indeed, I would agree that rewording to refer specifically to named 
> complex types would be more appropriate.  On the other hand, you seem to 

I received a similar suggestion from Martin Gudgin. The problem is,
I can't refer to the concept of "named complex types" since what I'm
trying to do there was to remove the entire concept of complex types.

I'm really ashamed for having such a poor control of my English.
I'd appreciate if you would show me a sentence that works as:

1. If a reader doesn't have any prior knowledge about XML Schema, then
   s/he can understand that all s/he has to do is to write <complexType>
   just as a place holder, and s/he can understand that the
   <complexType> has really no meaning at all.

2. If a reader knows what complex types are, then s/he can understand
   that what I'm suggesting is not to use named complex types.



> I expect to build tooling that will do quite smart things with such 
> constructions.  For example, I can build UI widgets that prompt for and 

First of all, thank you very much for providing a real world example of
how complex types are useful. Although I agree that there might be use
cases where complex types are really helpful, I don't think complex
types are useful for your particular example.

First, the whole point is to *automatically* create such a smart thing
from a schema.  Otherwise there is no meaning in specifically using
complex types to imply the relationship between elements.  If I or you
are going to create such a widget by hand, then all we need is good eyes
to find a similarity between <WIDTH> & <HEIGHT>.

And creating it automatically is easy to say, but hard to implement.
I've never heard that such a UI widget generator is out there.


Second, we don't necessarily use complex types to achieve what you've
mentioned. Model groups can serve the same purpose. It is equally
possible to have some smart tool create an UI widget from a model group.




> Consider, for example, 
> a substitution group that contains anything that's legal to put in a 
> <table> cell.  If you use substitution groups, then I can in my own 
> schemas invent new elements that are, in a controlled way, legal for use 
> in your table cells.

Once again, thank you very much for the example. But again I don't think
the substitution group helps to solve the problem. Honestly, I think the
substitution group serves no purpose.

First, let's consider another substitution group that contains anything
that can be placed in a <list> item. Now say I invent a new <kohsuke>
tag which I'd like to place both under <table> and <list> tag. The
substitution group doesn't solve my problem because I can't specify two
substitution affiliations.


Second, you can achieve the same effect by using the redefinition. In
cases like this, it is very likely that we have a model group called
"table.cell.class" in the original schema, which lists everything that
is allowed as the table cell. Indeed, this is a very common technique to
manage a large DTD.

Now all you have to do is, write a new schema, define the <kohsuke> tag,
and redefine the table.cell.class model group by adding the <kohsuke>
tag. This approach works even if I want to use that tag for other
elements like <list>.



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

Received on Thursday, 28 June 2001 17:30:38 UTC