Re: Common annotations first draft

[James Clark <jjc@jclark.com>]

> I think that even publication as a personal document should be discussed
at the TC.

I think the Working Documents section of the web site should reflect the
current working documents of the TC.  It makes no difference to the status
of a document whether the document is put on the web site in the Working
Documents section, or sent to the mailing list as an attachment, or put on
some other web site with a URL sent to the mailing list.  In all of the
above cases, the document is public information and is not in any sense
approved by the TC.  The Working Documents section is purely a convenience
for TC members and outsiders: instead of having to hunt through the mail
archives to find the documents that are being discussed, they can always
find the relevant documents on the TC home page.

> > If we adopt this approach to stating our goals, then I think we need to
> > explain why we aren't supporting other DTD features.  For example, we
should
> > say why we aren't supporting entity declarations and notation
declarations.
>
> I agree.  Why don't we support replacement of skipped entity references
with
> a mixed sequence?  (BTW, I certainly do not want to support entity and
notation
> declarations.)
>
> A very basic principle of RELAX Core is that the information set is not
touched
> at all.  Do we decide to change the information set by annotations (e.g.,
default
> values)?  If so, why don't we also support entities?
...

> > > - When a defaultable attribute is missing in an information set, it
> > >   should be possible for application programs to use default values.
> > >   For example, it should be possible to generate Java classes from
> > >   RELAX NG grammars with default value annotation and embed default
> > >   values in the Java classes.  Such Java classes do not require
> > >   changed information sets.
...
> I think that the last one is important and is not derivable from our
general goals.
> In the case of XML, it is clear that everything is done by the XML
processor.
> But we are not forced to everything with the RELAX NG processor.  (This
also
> relates to my conern about the conformance section.)  In fact, this is the
main
> motivation for creating this list.  What is appropriate layering?

Your comments to me suggest another general goal: "Multiple implementation
scenarios should be supported". That is, it should be possible to implement
the annotations spec in multiple different ways, including:

(a) builtin to the RELAX NG processor itself
(b) as a separate process that transforms the infoset using the schema and
annotations
   (i) where the separate process occurs before RELAX NG validation
   (ii) where the separate prcessor occurs after RELAX NG validation
(c) as a separate process that does not modify the infoset nor reports
default values and attribute types for each attribute and element in the
instance individually, but rather supplies information about particular
element names and attribute names that applies to the whole instance

(If I understood your comment about default attributes above, you were
contemplating an interface like (c).)

We should also perhaps then generalize Level 2 conformance, by saying that
the annotation procesor should make the information about default values
available to the application somehow, perhaps by modifying the infoset or
perhaps in some other way.

The desirability of a (c) like interface also suggests that we should
disallow name classes (ie we should require a single <name> element) both
for elements and attributes that use either a:attributeType or
a:defaultValue, eg

<element>
  <nsName/>
  <attribute name="foo:bar" a:defaultValue="baz"/>
</element>

should not be allowed, nor should

<attribute a:attributeType="IDREF">
  <nsName/>
</attribute>

James