OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Logical relationships between documents and schemata: was Re: usingnamespaces to version



Tony Coates wrote:

> On 03/05/2001 21:02:50 Jonathan Borden wrote:
>>Using the general rule that backwards compatible changes to a schema might
>>stay within the same namespace, the current schema for a particular
>>namespace would be identified by the purpose:
>>http://www.rddl.org/purposes#schema-validation

> I don't quite see how this can work.  I mean, from what I understand, the
> purpose is embedded in the RDDL document, so there is still no way of
knowing
> which actual version of the schema is required.  The problem here is that
of
> what is meant by "backwards compatible".  Many XML authors think of it in
terms
> of "instance documents which are valid under (some?) previous versions of
the
> schema remain valid instances under the new schema".  That's fine, but for
an
> application developer, a more useful definition of "backwards compatible"
would
> be "instance documents which are valid under the new schema are also valid
under
> the version of the schema against which the application was written".  As
you
> can see, the direction of "backwards" is opposite in these two cases, yet
both
> are perfectly valid views.  It is really because of this conflict that I
> consider it so important to be able to resolve the precise versions of the
> schemas used by a document, and namespaces with explicit versions do seem
to be
> the only practicable solution at present.


In order to have a rational discussion of this topic, we need to use precise
language regarding how different versions of a schema, or different types of
schemata, relate to a particular instance of a document and to sets of
documents.

To start this discussion I have somewhat formally define a set of terms:
http://www.rddl.org/SchemaAlgebra.html

It is important to properly determine the relationship of a new schema to an
old schema which is merely a special case of the general relationship of any
two schemata perhaps those of differing specifications (for example a schema
defined in XML Schema vs. one defined in TREX).

Since the RDDL description of a namespace includes a set of resources, this
set can be subsetted by selecting particular natures and purposes (for
example the set of all schemata related to a namespace, the set of all XML
Schemata related to a namespace etc.). Since a namespace is defined by a
URI, my intention is to extend this document to define logical relationships
between URIs and resources in general.

Let's now examine your first case of how "backwards compatible" might be
defined:

> "instance documents which are valid under (some?) previous versions of the
> schema remain valid instances under the new schema".

When Extension(Snew,Sold) all valid instances under the old schema are also
valid instances under the new schema.

Now let's examine the second case:

>"instance documents which are valid under the new schema are also valid
under
> the version of the schema against which the application was written".

When  Extension(Snew,Sapp) all valid instances under the new scheme are also
valid instances under the "app" schema.

When Sold = Sapp the two definitions are identical, and so I think that
these two definitions of "backwards compatible" are themselves compatible.

To the question of how RDDL might help: The designer of a namespace
(designer of the RDDL document describing the namespace) is free to use
version specific purposes assigned to each rddl:resource referencing a
schema. The purpose http://www.rddl.org/purposes#schema-validation is simply
a well known purpose for describing that a particular schema is used for
schema validation in a particular namespace. An application might, for
example, choose to label schemata with version specific purposes.

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org