Minutes for RELAX NG TC Meeting on 2001-08-09

[Michael Fitzgerald <mike@wyeast.net>]

Minutes for the RELAX NG Technical Committee meeting held Thursday, August
9, 2001 10:30 am EDT (UTC -04:00)

Attendees

James
Norm
Josh
Makoto
Kohsuke
Fabio
Mike

Missing

David

1. a:documentation issue: child or sibling:

James: simplest is wrapper content
Makoto: commented on the use of xml:lang
Fabio: likes following sibling
Makoto: will this force us to revise the schedule?
James: yes. do we want to post merely a public or a frozon document?
Makoto: frozen with some issues
James: the fewer the better
Kohsuke: following sibling fine
James: following sibling or wrapper in value with name and param
Makoto: 1 or 2 children, annotations intervening between value and content
James: explain?
Makoto: a:doc element parent with subcontent annotation, subcontent child
James: straw poll
 -Makoto: wrapper
 -Fabio: following sibling
 -Josh: following sibling
 -Norm: following sibling
 -Kohsuke: wrapper
 -Mike: following sibling
 -James: abstain
Makoto: I don't think we are quite ready to do this
James: before we freeze the document, we will use no wrapper
Makoto: fine to me
Kohsuke: I think I can live with it
James: prefer following-sibling, we can open an issue later

The proposed solution is to use following sibling in the annotation spec for
now.

2. From TREX: can we use foreign elements inside foreign elements?

Makoto: default values, use of RELAX namespace
James: good uses for annotations inside annotations; middle ground to have
RELAX NG inside
Makoto: I am happy to close this issue as long as I can raise an issue
againg if there are problems
Kohsuke: allowing them inside is easy, just close

Makoto's notes on this issue:

I talked about my old issue, which is "Shall we allow RELAX NG elements
within foreign elements?".
You might want to use this mail in your mailing report.

I mentioned two reasons.  One is default values.  James doubted I really
care.  He is right.
I don't.

The other reason is RELAX Namespace.  My worry is that this issue may have
some impacts on
validation in RELAX Namespace.

RELAX Namespace allows use of more than one schema language to constrain a
single document.
For example, we can have an XML Topic Map document containing XHTML
documentation.  RELAX
Namespace allows the schema language for XML Topic Map to be used the XML
Topic Map namespace
and RELAX NG to be used for the XHTML namespace.  Validation is done by
first decomposing a
multi-namespace document to a collection of single-namespace islands.  Each
single-namespace
island is validated against the schema for that namespace.

On the other hand,  RELAX NG elements within foreign elements should not be
validated
against the RELAX NG meta schema.  For example,
<foo:bar><rng:attribute><rng:element/></rng:attribute></foo:bar>
is allowed and <rng:attribute><rng:element/></rng:attribute>.  I am not sure
if this deviates
from the general principles of RELAX NG.

James argued that use of RELAX NG patterns within foreign elements have some
use.  Some annotation
might use embedded RELAX NG patterns.  I have also pointed out that some
documentation elements
may contain fragments of RELAX NG patterns.

James pointed out that we only have to impose some restrictions on RELAX NG
schemas referenced
from RELAX Namespace frameworks.  I think that he has a point.  I have
agreed to close this
issue for now.  I will raise this issuee again in the case that I encounter
a problem.  (Kawaguchi-san,
who implemented RELAX Namespace, does not see any problems).

3. publication status?

Makoto: ready
Kohsuke: why not?
James: 2 month review period, go with 1.0 after period
Norm: OASIS standards require a vote by OASIS membership, must be 3
implementations by OASIS members
James: we can produce a committee spec only
Roll call: are we ready to publish the spec?
 -James: Yes
 -Makoto: Yes
 -Fabio: Yes
 -Josh: Yes
 -Norm: Yes
 -Kohsuke: Yes
 -Mike: Yes

4. annotation spec: DTD compatibility?

Josh: do we want to be stuck with DTD only?
James: DTD is limiting
Josh: I can withdraw my issue
Makoto: I want to limit the scope
Norm: keep it to DTDs
Fabio: yes, I agree
Kohsuke: keeping it simple it is not necessary to limit to DTD
Makoto: Agreeing on what is simple is hard!
Josh: yes, I agree, I withdraw the issue

5. Should we attach an a:attributeType to an attribute element?

Makoto: yes this is hard
James: possible to work this out
Fabio: is this common?
James: I'll have to think about it ... the progress of the annotation spec
... its on a different level of maturity
Makoto: I am not sure I can agree on sections 4 and 5 yet...
James: we need to work out the precise restrictions on 4 and 5

6. Is the tutorial ready to publish?

Roll call:
 -James: Yes
 -Makoto: Yes
 -Fabio: Yes
 -Norm: Yes
 -Josh: Yes
 -Kohsuke: Yes
 -Mike: Yes

We agreed to publish both the tutorial and the spec as committe documents,
with the DTD compatabilty spec hot on their heals but not yet reflecting
committe consensus.

Molasses Mike (sorry to be so slow in getting out these minutes)
=====
Wy'east Communications     http://www.wyeast.net     mailto:mike@wyeast.net