> However, somebody (Bill LaForge?) thought that this stuff probably shouldn't go
> in the schema file, as it is application-specific, not schema specific. That
> is, while you would presumably have a single schema for a given document class,
> you would probably have multiple bindings. (Please correct me if I've gotten
> this wrong.)
I've certainly said as much in a number of presentations: the association
between these "XML Beans" (XObjects) is a function of the task being performed
with the data, not of the data itself. Some have called that "subject
oriented" computing. It's an old and well proven model. Most people see it
in terms of connecting different languages together via data format specs.
That's not the simplest model though, and many folk want simple models to
use (start with, evolve from, etc). Hence the recurrent desire of many
folk to have a schema support stuff like this -- they've heard of schemas,
schemas are new too, so just group it all together.
> Of course, there's nothing to stop you from naming bindings and keeping multiple
> different binding sets in a single schema file, but at some point I have to
> wonder why you need the schema information at all. Does an application that
> uses element bindings also need the other schema information, such as content
> model and attributes? It strikes me that the application generating the
> bindings is more likely to need schema information than an application using the
> bindings.
I see schema data as more describing the structure and semantics
of the information, and the bindings describing the behaviour in
the context of particular application tasks.
Data + Behaviour = Objects, as they say.
> > [David Brownell]:
> > >That sketch omits two important features: (a) importing bindngs
> > >defined for other namespaces, (b) document-specific bindings, such
> > >as for the "default" namespace or embedded in a document.
>
> I suspect the import problems could be solved by the general XSchema scheme of
> using XLink to import stuff from other files. Document-specific bindings could
> be handled by associating the appropriate XSchema file with the document through
> an XSchema PI. (I might be missing exactly what is meant by document-specific
> bindings here.)
The main issue I see with XLink there is that it's not done ... :-)
There were actually two radically different issues I lumped under that
moniker "document-specific bindings":
(B1) stuff associated with the "default" namespace (no URI),
presumably different for each document ... <binding .../>
elements not associated with a namespace URI;
(B2) documents which embed their own bindings, eliminating
the problem of managing separate documents for bindings.
The problem of referring to a set of bindings that was already defined
is straightforward -- as I noted, a <?bindings uri="..."?> directive
works. An XSchema PI is the same notion.
- Dave