[relax-ng] Minutes for RELAX NG TC mtg. 2001-10-18

[Michael Fitzgerald <mike@wyeast.net>]

Minutes for the RELAX NG TC telcon on Thursday, October 18, 2001 at 10:30 am
EDT (UTC -04:00)

Attendees

Fabio
James
Josh
Kohsuke
Makoto
Mike
Norm

Missing

David

Added to the Agenda...

To follow OASIS protocol, James asked for a vote to allow those who are not
members of the RELAX NG TC list to subscribe to the list.

Passed. Others outside of the TC may subscribe to the list.

Agenda

1. Resolution of errata for attributes representing namespace declarations.
Is the solution James implemented in the spec (section 7.4) OK?

New wording found in 7.4 was accepted but it needs to be moved as the check
required brought up another issue. Should these values be checked
post-simplification or before step 4.11?
Kohsuke: I think it is easier to check before.
James: [Checking later] presents an awkwardness and does not buy us
anything.

Agreed that checking should come before. James will take an action item to
see to this.

2. Issue 57. Is the solution in the spec OK? This issue deals with
whitespace (ws) normalization and datatypes.

Makoto: I have one question. In James's email of Sept. 13 an inference rule
for an element...ws-1 and ws-2 range over ws and empty elements...
James: [My proposal] provides much more uniform rules for element and
attributes, better results for list/token, more DTD compatibility, [etc.]
Kohsuke: I think I implemented it but I am not sure.
James: It's in my test case.

Passed. Should be implemented according to James' proposal
http://lists.oasis-open.org/archives/relax-ng/200109/msg00071.html.

3. Issue 40. Restriction on interleave.

James: Makoto, did you contact Hosoya-san?
Makoto: I sent him an email but did not respond yet.
James: I think there are two issues to be resolved. (1) do we allow <text/>
in both operands of <interleave> and (2) do we allow <interleave> inside
<list>?
James: So will having both operands as <text/> cause shuffle automata to
explode?
Makoto: I believe it can...it is unreasonable to allow it then.
James: If you apply mixed on something that is already mixed in complex
parameterization, you can run interleave by two automata in
parallel...allowing <text/> breaks that intuition...I haven't found any
papers that show an analysis of worst case problems...I favor disallowing
it.
Kohsuke: I am inclined to prohibit it.
Makoto: So am I.
James: [I will do some research] on disallowing <text/> as both operands of
<interleave>.

<interleave> in <list>
Kohsuke: Allowing value but prohibiting data, hard to do correctly...
James: Both operands must have the same datatype or you can't compare them
in a meaningful way...either it's not worth it or you can allow it but
values in both operands have the same datatype but must not contain the same
value.
Makoto: To keep it simple I prefer to disallow this.
Kohsuke: I think <list> in <interleave> can be useful...
Makoto: Where?
Kohsuke: You can use it to represent some restrictions...but perhaps this is
the same as using <choice> and <oneOrMore>?
James: Then expand it to a bunch of <choice>s? Does everyone understand
Kohsuke's use case? In XML Schema you can have tokens in a list such as
extension/restriction/substitution which you could represent with
<list>/<interleave>/<optional>.
Fabio: I think we should disallow it.
Makoto: Disallow.
Kohsuke: Allow.
Norm: Allow. Nice to be able to do what the other guy can do.
Josh: What impact on the spec? Will it be difficult to implement?
James: I don't think so...not drastic.
Josh: I would allow it reluctantly.
Mike: Allow if Kohsuke's case is useful.
James: On fence...this is finely balanced. A structured attribute is a
marginal case. It's dodgey but it seems more natural. From a political side
we want to be able to do what XML Schema can do but it will add complexity.
Kohuske: Let me try to implement it.
James: I will try to implement it too. We will discuss next week.

4. Issue 65. Attribute wildcard. The current proposal is that, after
simplification, if an <attribute> has a <nsName> or <anyName> child then it
must have a <oneOrMore> ancestor.

Makoto: I haven't heard anything yet. I have sent two emails.
James: We sure don't need the restriction...
Makoto: We can reinterpret automata during processing...using homomorphism,
inverse schema. If we do this -- it is very formal -- it will [handle the
case] nicely.
James: At the moment can we not use this mathematic characterization because
we don't have the restriction?
Makoto: Yes.
James: It seems plausible but is it a trick for the algorithim to do
this?...need to brush up on homomorphism but it sounds right.
Makoto: I will write it up.
James: We can decide this next week.

Other agenda:

James: Do we want to submit RELAX NG as a W3C note? Is there any member
company that can do this for us?
Josh: NIST can.
Mike: I think a W3C submission will undermine the legitimacy of its status
as a [potential] OASIS standard.
James: I think we need to work on some sort of generator to produce XML
Schema [etc.] output from RELAX NG input.
Fabio: I will submit an article to xml.com.
Josh: I'd like to see an emacs mode for RELAX NG like PSGML.
Mike: When will James and Makoto write a book?
James: It doesn't need a book...
James: We don't need to rush anything.
Norm: Agreed.

Mike
=====
Wy'east Communications     http://www.wyeast.net     mailto:mike@wyeast.net