xml-dev - Re: Schema concepts

[THOMAS PASSIN <tpassin@idsonline.com>]

Bill la Forge wrote:
<snip/>
>
> Now, lets say we have XML type tied to a class, somehow, and we
> have attached our methods by some means. Now an element can
> reflect a use of that capability. In fact, by defining fixed values in the
> schema, we can configure the common capability for a particular
> usage without having to create any additional code. This feels like we've
> got things in the right order.
>
I sense something here closely related to some of my thoughts, but I'm not
sure it's what you were thinking about.  When you say "we have XML type tied
to a class, somehow, and we have attached our methods by some means", I
think of these attachments as being specific to some application (or maybe
interface).  The attachments could be different for a different application.
In this way, the same element could belong to different classes for
different applications.  This is consistent with the fact that an element
contains only "data", not "methods", whereas a class ususally contains both.
This makes an element a degenerate class (in the technical sense, not as a
denigration) leading to many possible "solutions" (in this case, classes).

Looking at it in this way, an element could be considered to be or belong to
a degenerate or incomplete "class" - the application supplies the behavior
(interface) while the schema supplies the data definitions.  This makes
sense to me.  Is this anywhere close to what you were thinking about, Bill?

On the other hand, why shouldn't a schema be able to define behavior in some
way?  We might want to call it something else since people tend to think of
a "schema" as a description of a data structure alone.  This looks like
major expansion of the scope of work of the xml-Schemas WG, though, and it
would take a long time to develop.

> Frankly, if we aren't talking about implementation, I suspect type has
> no meaning. If type is more than syntatic sugar, then it seems that it
> must be a way of addressing some underlying semantic that is common
> to various elements, where the elements reflect usage.
>
I would say that the type definitions in xml-Schemas Part 2, allow us to
impose some additional structure on an xml document.  In its turn, xml
allows us to impose additional structure on a plain text document.  This
suggests that we will be seeing a progression of ways to impose more and
more structure onto documents.  This will be useful, but add complexity.

In fact, xml-Schemas Part 1 is already adding more structure by using "type"
both for primitive types like integers and for structured types like
elements.  I actually don't quite see why this is so, since the primitive
types can only be in the content (or attribute values) of elements, and do
not function as elements themselves, but there it is.

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
***************************************************************************