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]

Re: Logical relationships between documents and schemata: was Re:using namespaces to version

Tony Coates wrote:

Let me comment separately on this issue.

> >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
> >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.
> Yes, but given that my instance document may have elements in an
> namespace URI, for which there are multiple schemas (all listed in the
> document), how do I determine which schema is the correct one?  Remember,
> answer may not be just the "schemaLocation", because if I have schemas
> or including schemas which themselves import or include schemas, it may be
a big
> job to determine just what all of the relevant schema versions are.

Part of this is an issue with creating new versions of schemata. The new
schema needs to know which modules it is supposed to import and there are no
two ways around that. makefiles for software projects can get complicated,
especially when they are parameterized for versioning and other options.

The only thing RDDL will probably help with is getting to the schema
"driver" but the driver still needs to know how to find the correct modules
it includes.

If we are considering validation across multinamespace documents where the
schemata for the various namespaces are expected to reside at the namespace
URIs (via RDDL), I agree that xsi:schemaLocation doesn't do the trick.

I am not sure how people are contemplating such a thing, but perhaps this is
another reason to consider something like a rddl:schemaPurpose attribute
which could be fed to the RDDLURL resolver used to fetch the resource, like
xsi:schemaLocation, this attribute would probably need to accept a list of
purpose values which would be tried in order e.g.