xml-dev - Re: Schema concepts

[THOMAS PASSIN <tpassin@idsonline.com>]

Stefan Haustein wote, responding to my post that responded to Jeff Lowery's:
> THOMAS PASSIN wrote:
> >
> (...)
> >
> > Using OOP to build an application does not automatically require that
every
> > piece of the schema be an OOP object.  That might or might not be a
useful
> > approach.  An XML document may be used in a large number of ways,
requiring
> > different methods.  So I don't think that the WD is headed in the wrong
> > direction here.
>
> While I agree to your statement, I do not understand the conclusion:
> Wouldn't a simplified XML Schena spec help all processors, regardless
> if they are OOP or not?
>
Yes, I think simplicity is ***very*** important.  As simple as possible.
The hard part comes with the addendum: "but as complete as necessary".
Efforts to be complete tend to sacrifice simplicity, don't they?  In part, I
imagine, XML-Schema is complex beause the authors are trying to be complete
about difficult abstractions.  So there are really two issues, aren't there?
1) Is the correct set of abstractions present? and 2) if they are, are they
expressed with as much simplicity as possible?

The fact that there have been so many weighty questions on the list is a
clear tipoff that more work needs to be done on the WD.  In other words, if
your readers don't understand you, it's better to revise and rewrite than to
keep on explaining what you "really mean". Are we dealing with alternative
1) or 2)?  I suspect it's both, and I think different posts focus on one or
the other.

> Or do you see a concrete advantage of the type/element distinction
> in your application field?
>

I have to confess that I am not completely settled in my own mind about
whether there should be a distinction between "element" and "type".  The
main issue being, what is a "type" anyway?  An element we can probably agree
is more or less "That thing with start and end tags - oh yes, it can contain
other elements too."  But "type"??? You can have "types" without any OOP
approach.  In some languages, two things are can be type compatible if they
take up the same number of bytes, and not otherwise.  Some people consider
an SQL table definition to define a type.

And then there is the question of the distinction between "class" and
"type".  This is very important to some people, and unimportant to others.

Even if we stuck with an OOP paradigm, there is not universal agreement on
what either a class or type is.  For example, forget methods, OK, but don't
we have to leave in inheritance?  But how about multiple inheritance or
inheritance with restriction (i.e., the child omits some properties of the
parent)?

When I reflect on the above, it seems to me better to keep an element as
separate from a "type" - it ought to make it easier to use without having to
invoke a lot of machinery and definitions, if that's what one wants to do.
And also, it behooves the standard writers to be very clear about what a
"type" is and how to use it.  Now, to make a "type" conveniently useable to
C,C++,Java,Smalltalk,Python, and Lisp/Scheme users - just for starters - is
probably going to take some doing.  It's probably better to try to make our
"type" adaptable - nothing that would prevent such use, in other words- by
these common application environments , than is is to cause a "type" to
exactly agree with the notion of "type" in any one of them.

Regards,

Tom Passin


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************