Minutes for RELAX NG TC Meeting 2001-08-16

[Michael Fitzgerald <mike@wyeast.net>]

Minutes for the RELAX NG TC Meeting held Thursday, August 16, 2001, 10:30 am
EDT (UTC -04:00)

Attending

James
Makoto
Kohsuke
Fabio
Mike

Missing

David
Josh
Norm

1. Guidelines for using XML Schema Part 2. Are we still agreed we want a
document for this? Does anybody have anything to add to the set of
guidelines I sent to the mailing list?

Makoto: I think this will help users a lot, even implementers
James: I agree with Kohsuke that we should not deprecate the parts of XML
Schema Part 2 that don't work
Makoto: I recommend that Kohsuke work as co-editor with James on the
guidline document
James: So we all agree that we should write such a document [non-normative]
All: Yes

James and Kohsuke, then, will write this document.

2. Should we produce some sort of design rationale or white paper
explaining/justifying the design decisions we've made? (Rick Jellife
suggested this on xml-dev.)

Makoto: I see two such papers: (1) one for design principles and (2) another
for what we have postposed such as identity constraints
James: I think they could go together. Talk about inheritance...why we
didn't do it and how you can achieve the same effect
Mike: I think it will be good for us to be bald faced about why and why not
we are doing things
Kohsuke: I recommend that we do this in a FAQ format
Makoto: I like that approach
James: Yes, you could frame a lot of rational in this way, non-normative
Kohsuke: we could host the FAQ on sourceforge
James: we could work this out...it could be a link off the OASIS page...we
will talk about that
Fabio: I think it works well from a marketing perspective
James: we can all pose questions to be addressed, but make them pithy or
concise and to the point, not "Why is RELAX NG so wonderful?"

All are asked to submit questions (possibly with answers, too) to be
included in the FAQ.

3. Restriction on patterns within <attribute a:attributeType="..."> (issue
61)

James: what does this say about what content is allowed?
Kohsuke: I am inclined not impose anything!
Mike: seems like we shouldn't tell them what to do
Makoto: deciding on these restrictions is hard to do
Kohsuke: leave things up the annotation processor
James: I am not sure it is worth it to get into what restrictions are
required...can we just close this issue?

This issue is closed. We will not restrict patterns within <attribute>
elements with a:attributeType?

4. What values should we allowed for a:attributeType? (issue 59)

Makoto: Does DOM support attribute types? SAX does.
Kohsuke: Yes. XML Schema normalizes whitespace in attribute values.
James: I think whitespace normalization of attributes should be a separate
issue, layered on top or RELAX NG processing. We are also not dealing with
simple type assignments. There are also issues of external entities, and the
fact the DTDs are not namespace aware, they process the qname as a name...
Mike: I wonder what our rationale is...could we not just use <data> with XML
Schema part 2 datatypes to assign datatypes to attributes, such as ID,
IDREF, as well as with a:attributeType? What shall we say the difference is?
James: well XML Schema part 2 assigns the type, but part 1 tells how to do
the processing...it is another process on top of datatype assignment. I
think we need to give this more thought.
Kohsuke: let's talk about the next issue...
James: the next issue is moot given that we need to think this through some
more. We need to get an a:attributeType rationale in place before we talk
about this.
Makoto: sections 4 and 5 of the annotations spec will be hard to work out
James: perhaps we need to come up with a compatability datatype
implementation that is separate from part 2 datatyping?

5. What should a:attributeType be attached to? (issue 62)

Didn't discuss. See item 4.

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