Minutes for RELAX NG TC Meeting 2001-08-02

[Michael Fitzgerald <mike@wyeast.net>]

Minutes for RELAX NG TC Meeting on Thursday, August 2, 2001 10:30 EDT
(UTC -04:00)

Attendees

James
Makoto
Kohsuke
Josh
David
Norm
Mike

Not Attending

Fabio

The meeting started about 10-15 minutes late due to a small tele-lapse.

1. Keys

James: There is an inline approach and an out of line approach. IDs are
inline, XML Schema takes a mixed approach. Currently we are inline with some
extensions. Four possible choices:
1. stick with our current generalized approach
2. simplify or cut back, that is make it closer to ID/IDREF
3. take out keys altogether
4. take keys out of the RELAX NG spec and put them in a common annotations
spec
A little bit of my opinion. I don't like 2 which amounts to compatibility
hacks. I don't want to change the infoset. But i think we should dare to do
less.
Makoto: I like number 2. I offer two reasonable ideas.
1. produce an independent spec
2. produce an independent spec for compatibility hacks
James: We couldn't do it by next week.
Makoto: I can't live with the current spec.
Norm: James doesn't like 2 and Makoto doesn't like 1 and I don't like 3, but
I am okay with 4.
David: I could go with that. I like the idea of adding a lightweight spec.
Josh: We need to support ID/IDREF at a minimum.
James: I think it [another spec] would be a good thing, allow us a layered
approach, and help us out in the future.
David: I have found that in the document case, ID/IDREF is used, but in the
business case, it is not used.
Makoto: Same applies to default values.
James: So if we have a common annotation spec, it will contain default
values, ID/IDREF, and a common documentation element.
David: I am against that. One can just use comments and that would be good
enough.
James: Well if you just use XHTML, what does a xhtml:p mean?
David: XHTML can be part of the mix. A clean mechanism can be comments and
meta text.
Mike: I prefer a documentation element. It is low cost and provides a simple
conventional mechanism. We won't force them to use it. They can use XHTML if
they like.
Norm: I can go along with that. I would not naturally choose XHTML!
Kohsuke: I like a simple element. It makes things explicit.
Makoto: I wanted XHTML Basic, but that's about 40 tags. Okay with a simple
element.

TC agreed to pull out keys [All key info? -mjf] from the main spec and
produce a common annotation spec.

2. Section 7.1

James: What do people think of prohibited paths?
[People generally like them.]
James: What about <start>? Do we prohibit <text>, <attribute>, <data> and
<value>?
Makoto: Eventually. Not for now.
Kohsuke: Prohibit one or more?
James: Prohibit group/interleave? Maybe we just allow choice/element/ref?
Makoto: With this you cover 99%!
James: I propose that we support choice/element/ref.

TC approved this.

James: What about issue 45? [restrictions on oneOrMore]
Makoto: I don't have to argue this anymore. I don't care.
James: Could we "pretty please" close 45 then?

TC approved this.

James: What about data/except//list?
Makoto: This is a bit strange.
Kohsuke: I imagine people exclude a list of tokens...
Makoto: Why not just <list>, not <data>
James: Can't put <except> in <list>.
James: Who wants to disallow this?
[Josh, Mike, Norm, Makoto, David]
James: Who wants to allow?
[Kohsuke, James]

TC voted to disallow.

3. Issues. New approach.

James: Our current system isn't working. What if we go with this:

(a) Anybody can add an issue (as in our original process)
(b) A newly added issue gets a "proposed" status
(c) After the first time a proposed issue is discussed it changes status to
either "closed", if it was resolved, or "open", if it was not.

Kohsuke: Put Issue: in subject line so I want miss it.
James: Please use restraint in submitting issues at this point.

Makoto: I want to talk about when we will have a spec. I am giving a talk on
August 17.
James: [after some discussion] Let's publish it on August 10. I will put out
a new draft and allow you to comment.

4. Fallback mechanism for unknown datatype library (issue 58).

Kohsuke: I like James proposal. Just don't require them to do anything if
they encounter a unknown datatype library.
David: This fits the ebXML way of doing things.

TC closed this issue. Implementers are not required to do anything if they
encounter an unknown datatype library, though they may want to do something.

Makoto: We are almost done!!

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