Re: [relax-ng] Some ideas about simple type assignment

[James Clark <jjc@jclark.com>]

> Because most programmers would like to use such additional descriptions
> rather than schemas.  However, it would be certainly very nice if the (@a,
int)
> pair can be generated from the schema.  In this case, it is certainly
possible.
>
> If we do not use any descriptions other than schemas, those programs which
> perform simple type assignment have to analyze schemas.  That will be very
> hard for most people.  As a result, only validators would be able to do
> type assignment.  I think that separation of simple type assignment and
validation
> is very important.

I agree that it is good to be able to have a description of type assignment
that is separate from the schema.  I also agree that it is good if this
description is something that it is possible for programmers to author
directly, rather than being forced to generate it from a schema.

However, I think that being able to generate the type assignment description
from the RELAX NG Schema is not merely something that would be "very nice"
but rather is an essential requirement.  If we are not doing this, I don't
see the justification for doing this as part of the RELAX NG TC.

The technical challenge seems to me to be to devise a format for describing
type assignment which is such that:

a) it can be authored directly,
b) it is practical to determine whether the type assignment information that
is implicit in a RELAX NG schema can be represented in this format, and, if
so, to generate a description in this format, and
c) it is practical to determine whether an independently-created description
is consistent with a RELAX NG schema

Paths may very well be an important ingredient in such a format, but I don't
immediately see an algorithm for doing (b) with your suggested format.

I think the requirement (b) will be an important consideration in guiding
the choice of the capabilities of the format.

> > > It is possible to slightly extend this by allowing "//"
> > > everywhere, for example.  But I think that fixed paths are good
> > > enough
> >
> > It's very common for schemas to have elements which allow arbitrary
> > well-formed XML.  For example, RELAX NG allows annotation elements to
> > contain arbitrary XML.  I'm not sure what criterion you have in mind for
an
> > assetion's being correct wrt a schema, but using the obvious criterion,
no
> > simple type assertion would be correct wrt to such a schema.
>
>
> For such schemas, the framework I suggested does not work.  I think that
> allowing arbitrary well-formed XML is a bad idea.  Only foreign-namespace
> elements should be allowed.

I think allowing arbitrary well-formed XML within foreign-namespace elements
is both very common and very natural.  If you are designing an extensible
vocabulary and you want to make it easy for programmers to check the
constraints imposed by the vocabulary by hand rather than automatically
using a schema language, then the possibility of subtrees with arbitrary
well-formed XML arises naturally: it is unnecessary extra work to require
programmers to do some complex checking on the content of an extension
element, given that the application is then going to ignore that element.

I believe it is an essential requirement to be able to deal with this
situation.  However, I think it may be possible to extend the framework you
suggest to deal with this. We would need to add the idea that certain
subtrees are skipped/ignored for the purposes of type assignment.  In
addition to being able to associate a path with a datatype, we would also be
able to associate a path with the root of a skipped subtree. For example,

  * - rng:*   skip


or

  rng:*     include
  *         ignore

This is similar to what you would do in XSLT:

<xsl:template match="*"/>
<xsl:template match="rng:*"><xsl:apply-templates/></xsl:template>

In the schema, there might be an annotation on the element that contains the
subtree to be skipped.

James