xml-dev - Re: Schema concepts

["Bill la Forge" <b.laforge@jxml.com>]

From: THOMAS PASSIN <tpassin@idsonline.com>
> > 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?

Yes. I think there are 3 things going on, which adds to the confusion:

1. Data models--perhaps XML types

2. Data uses--elements

3. Implementations--data models with methods.

Now, of course I want to be able to use the same implementation in a program
when moving data between data flows using different markup languages. This is
why I'd rather associate data type to implementation rather than derive it, since
programmers rarely have control over the markup languages of the data they are
given. But this is a side issue and a source of dispute right now, as many are strongly
committed to a particular approach.

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

Natrually, implementations will vary depending on how the documents are being
processed. So it would be nice if the binding to implementations were seperate.
This is doable when a schema is compiled into code for the data representation.
Then all you need is a list which binds elements and attributes to subclasses of
the generated code.

But when you don't generate code from a schema (which I prefer), then the
bindings are much more difficult to seperate. Now you must specify, for example,
which field to use when an element occurs at a particular point in another element's
content model. 

the course I've taken is to extend a schema with binding information. I call this
a binding schema. I think we could use wizards which could help in the process
of generating this information, given a schema and a set of classes.

My first attempt at a binding schema is QJML:
    http://www.jxml.com/quick/schema/qjml.html

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

Well, if a regular expression is used to define a type, it is handy to be able to
name the type when defining attributes--makes the maintenance easier. It also
clairifies the semantics, as there is an indication that all primitives of the same
type will probably use the same implementation.

Bill


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