OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: TREX TC minutes from 2001-04-19

[Correct and amend at will. -mjf]

TREX TC Minutes 2001-04-19

James Clark (chair)
Kawaguchi-san (observer)
Josh Lubell
Norm Walsh
Mike Smith
Don Smith
Mike Fitzgerald

James Tauber
Eric van der Vlist
Fabio Arciniegas

Next Meeting: Thursday, May 3, 2001, 10:30 EDT (which is UTC -5:00 or UTC


1. Exclusions. In light of the removal of concur, we discussed whether
exclusions ought to be added to TREX v1.0. Murata-san believes, as does
James, that it is syntax sugar and that it could be easily postponed until
v2.0. Norm feels that exclusions are right on the line between 80/20, but
that we could live without them in v1.0. James suggests that exclusions be
placed on the back burner as we have "bigger fish to fry."

2. ID/IDREF (uniqueness constraints). DTDs and XML Schema both support
them -- should TREX v1.0? Norm said he doesn't see how  we can't support
identity constraints! James said it was not at all easy or not trivial to
implement. [Murata-san said something about identity constraints in three
grammars, but I did not catch what it was.] Revisit.

3. QNames. Eric has expressed his opposition to QNames in early email on the
TREX list. James restated a sentiment that it is bad to rely on namespace
declarations. Murata-san believes that reliance on QNames violates basic XML
parsing, as in some cases an arbitrary prefix must be changed when it
clashes with another prefix in a document. Mike F. wondered aloud if we can
stray from the Namespaces in XML recommendation without some difficulty.
James suggested that we punt.

4. minOccurs/maxOccurs. Should we provide range restriction other than
<oneOrMore> +, <zeroOrMore> *, and <optional> ?, as in DTD? Josh believes
that being able to validate on a given range, other than 0 to Infinity, is
"highly desirable." Murata-san feels that it is not a minimum requirement,
however. Kawaguchi-san agreed. Norm does not feel it is a show stopper, but
it will make TREX' validation weaker. Don offered anecdotal evidence that
database people really like a min/max capability.

5. Non-deterministic patterns. TREX, as it stands, does not prohibit
obfuscatory patterns. Murata stated his concerns about the non-restrictions
on patterns in TREX, e.g., being able to define elements within attributes
is misleading. We punted on this one as well.

6. Informal restrictions on type strings. Murata-san suggested that TREX
could be more "relaxed" about this. James said that this should be resolved
by e-mail.

7. Documentation element. Mike F. expressed his satisfaction that since
elements and attributes could be included from any namespace (such as
xsd:annotation/xsd:documentation) there is little need for a TREX
documentation element. Murata-san mentioned the feasibility of limiting
"foreign" namespaces in certain places. The consensus [I think] was to take
no action and to leave it at the current status, i.e., elements or
attributes anywhere.

ACTION: Don and Josh to collect more evidence on the popularity of min/max
ACTION: Kawaguchi-san will act as the issues monitor and will publish a list
of TREX v1.0 issues.
ACTION: James and Murata-san will draft a message to XML-DEV regarding the
marriage of RELAX and TREX and contact journalists as well.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC