Re: Minutes for RELAX NG TC 2001-06-14

[Murata Makoto <mura034@attglobal.net>]

Michael Fitzgerald wrote:

> 2. General principles.
> 
> TC discussed for some time the relation of our data model, patterns, and XML
> 1.0. Murata-san had used the term "generate" and James asked for
> clarification. Murata-san was using the term in light of regular tree
> languages that can generate acceptable sentences that can then generate

"A pattern p generates a tree t" is the same as "A tree t is valid against 
a pattern p".

> trees. [Clarify?] James claims that you cannot use the current inference
> rules to prove that the current grammar allows anything except XML 1.0.

There are some exceptions.  <group>, <interleave>, and <oneOrMore> permit 
colliding attributes.  (In my understanding, we have agreed to change them.)

> Kawaguchi-san suggested that we write a simpler inference rule. It came down
> to the whether RELAX NG should report non-XML 1.0 patterns as errors or
> simply not allow them.

... whether RELAX NG should allow patterns that generate non-XML data
such as colliding attributes or elements/attributes in attributes.
 
> TC voted in favor of 'error' over 'not allowed' in regard to non-XML 1.0 

... "syntax error" over "does not match anything, i.e., <notAllowed>".

> 3. Issue 21. Should we allow duplicate attributes?
> 
> This was in response to Murata-san's suggestion that we add
> <multipleAttributes>. James stated that we could disallow duplicate
> attributes by adding an antecedent that states that attribute bags (bags are
> unordered collections) must be disjoint.

My first mail proposed to syntactically disallow patterns that generate 
colliding attributes.  I believe that the TC voted to accept this proposal.

http://lists.oasis-open.org/archives/relax-ng/200106/msg00116.html

Note:  Unlike other minor comments from me, this decision has profound 
impacts on validation.  This really achieves unification of RELAX Core and 
TREX.

http://lists.oasis-open.org/archives/relax-ng/200106/msg00118.html

My second mail proposed to introduce <multipleAttributes> so as to make 
this semantics explicit.  James and Kawaguchi-san said that we can simply 
change the inference rule for <oneOrMore>, and the TC voted to do so. 

http://lists.oasis-open.org/archives/relax-ng/200106/msg00127.html
http://lists.oasis-open.org/archives/relax-ng/200106/msg00130.html
http://lists.oasis-open.org/archives/relax-ng/200106/msg00130.html

> TC voted not to adopt <multipleAttributes> syntax, but James said we could
> adopt Murata-san's related algorithm.

We have agreed to syntactically disallow patterns that generate 
colliding attributes.  My first mail shows such an algorithm.  
The semantics of <oneOrMore> was changed so that it does not generate 
colliding attributes.

I believe that we have also talked about whether we should allow <oneOrMore> 
containing <attribute>s which match a *finite* set of names.  Nobody had 
strong opinion, and we have agreed to allow such <oneOrMore>.

> 4. Issue 19. Should we restrict elements and attributes inside attributes?
> 
> TC voted that yes we should restrict elements and attributes inside
> attributes.
> 
> 5. Issue 33. Should we restrict element and attributes inside of list?
> 
> TC voted that yes we should restrict elements and attributes inside of list.
> 
> 6. Issue 18. How shall we handle restriction wrt data, value, and list?
> 
> This issue is a bit tricky and we decided to allow TC to discuss this
> further by e-mail. Murata-san had earlier presented some theoretical
> material on this issue. James asked him to expand on this and mail it to the
> list. We hope to work out details on the list and reach a decision next
> week.

Kawaguch-san was concerned about closure under boolean operations.  I 
said that closure under union and intersection is important, but closure 
under difference is not.

 
> Other Issues
> 
> We talked about the need to start developing a suite for conformance
> testing. James suggested a SourceForge project so people could check things
> in, both valid and invalid. No volunteers to set this up. [We had discussed
> in an earlier meeting using SourceForge for documentation. I believe Fabio
> volunteered to help out there.]
> 
> Murata-san is working on getting funding for his work. [A suggestion was
> made that he set up shop in Hawaii, perhaps with a branch in Bangkok. %^}]
> 
> Our congratulations to James for his implementation of RELAX NG this week,
> now called Jing. (/Jing/ means /true/ in Thai.)

Incidentally, /Makoto/ means /true/ in Japanese, and another (probably 
Chinese) pronounciation of the kanji for /Makoto/ is /shin/.  :-)

Cheers,

Makoto