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
