Re: [relax-ng] Proposal: remove annotations from the compact syntax

[James Clark <jjc@jclark.com>]

> *) They make the definition of conformance double-jointed.  Instead of
> just    saying that compact-syntax schemas should work just like
> equivalent    XML-syntax schemas, we are stuck with saying that
> annotations should    be *converted* correctly, since the effect of
> either kind of annotation    on a strictly conforming RNG processor is
> nil.

I think the answer to this is to have two classes of conformant
compact-syntax processor:

- a validator, which can ignore annotations (just like a validator
in the XML syntax)

- a translator, which must be able to generate an XML-syntax schema
which differs from the result specified by the formal definition
only in particular, limited ways which the spec defines

> *) They are no substitute for coming up with a proper compact syntax for
>    RNG variants like RelaxNGCC or ooRELAXNG (I hope I have the caps in
>    the right places).  What users will want is an integrated syntax for
>    such extensions, not just an all-purpose kludge whose semantics may
>    in certain cases be incorrect.

I agree that annotations in the compact syntax are not a good solution
for RNG variants.  However, there are many, many things for which they
are a good solution.  Let me give some examples.

- a:defaultValue from our own annotations spec

- data binding: with data binding you often want to be able to tweak
the classes that the implementation generates automatically from the
schema, for example to control the class name or field name,
or how inheritance is used

- annotations specifying schematron rules

- xsd:key, xsd:keyRef, xsd:unique used as annotations on
<element> patterns

- specifying the unambiguity constraints that a schema is intended to
satisfy; for example, a schema might use an annotation
x:singleType="true" to specify that the schema satisfies the
"single-type" constraint checked by RelaxMeter; a validator could then
automatically check whether the schema does indeed satisfy the
intended constraints

- controlling conversion into other schema languages; when converting
into DTDs or XSD, there is more than one possible way to do things,
and the user may wish to tweak how the conversion is done; for
example, for example controlling whether a definition gets mapped to a
complexType or a group or an attributeGroup; controlling the
targetNamespace for a particular file; when converting to DTDs,
controlling the use of marked sections.

With such things, the volume of annotations is typically small enough
that it does not overwhelm the non-annotations, and I think the
existing syntax works just fine.  An integrated syntax for such things
would in my view be

- far too much work to be worthwhile and

- less useful than the annotations because of the loss of
interoperability.

> *) They make the BNF definition of the compact syntax much harder to read,
>    since they are basically clutter but have to be handled separately in
>    almost every location.

Annotations are not mentioned in the EBNF in section 2 of the spec.
They only affect the formal definition.

> *) They make the formal definition in the Appendix much more complicated

This is true.  But at least this is something that implementors have
to deal with rather than users.  I think with the compact syntax it is
acceptable to make implementors suffer a bit to make life more
convenient for users.

>    and likely to contain bugs.

It's the job of the TC to carefully review the spec to eliminate these
as much as possible.

> *) They are still ugly.  :-)

I think they're ugly for RNG variants; however, I think there are
appropriate uses for which they are not ugly.

James