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: Minutes for RELAX NG TC 2001-07-19

Minutes for the RELAX NG TC meeting held July 19, 2001, 10:30 am EDT
(UTC -05:00)



Not Attending

Note: Mike Smith has dropped out of the TC.

Next meeting: Thursday, July 26, 2001, 10:30 am EDT (UTC -05:00)

1. Using <key> and <keyRef> elements rather than key and keyRef attributes
(issue 43).

TC voted to move key/keyRef from attributes to elements.

2. Empty strings as keys and keyRefs (issue 53).

James commented that matching whitespace changes the rules of key/keyRef and
that whitespace usually causes problems. He proposed that we close this
issue by adding an antecedent to the inference rule not(s = "").

TC voted to close this issue based on James proposal.

3. Allow <list> of <keyRef>? Allow <list> of <key>?

James stated that <list> in keyRef was obvious and that he did not see a
reason to not allow <list> in key. However, Makoto felt that <list> in key
(1) would have a negative impact and (2) would make future identity
constraints harder and (3) there was no reason to allow it, and finally (4)
he didn't want to complicate future extensions by putting this functionality
in place.

James suggested that we put this issue on hold and we moved into a
discussion on the spec.

9. Publishing the spec as official committee document.

James felt we could produce a spec as an official committee document, even
though we may have a half dozen undecided issues, as the remaining issues
will not be an impediment to implementers. Such undecided issues could be
mentioned in the spec. We hope to have a working draft of the spec by the
time Makoto gives his presentation on RELAX NG at Extreme Languages in
Montreal. [We thought that date was August 24 but actually it is August 17.]
During the comment period of about two months the TC will essentially "go to
sleep." The comment period will end on something like October 24 which would
allow time to produce a final version of the spec by October 31.

The TC was in favor of this approach [though some additional details need to
be worked out].

4. External grammar reference mechanism (issue 55).

James: this will be a meaty one
Kohsuke: not happy with this, kind of a dead end for me
James: local block scoping is not like module scoping, hierarchical vs. flat
ns, what do you do with merged grammars then?
Kohsuke: I am inclined to use some sort of preprocessing
Makoto: if you use the same URI, implementations don't have to load the
schema many times [?]
James: an external reference hard to do only once, but maybe we can add
something later in v2.0
Kohsuke: what about a named grammar?
James: that's close to a module, not just in a separate file
James: we could add a note to the spec
Makoto: what will the note say? mention both possibilities?
Kohsuke: I don't want to introduce this, it doesn't solve any problems
James: I marginally prefer a parent define
Kohsuke: we could wait of public comment

5. Processing of datatypeLibrary and ns attributes (issue 47).

[this discussion was hard to follow; please offer any corrections you may
have. -mjf]

For a more up to date discussion on this issue, see James' post at:

James: one issue is what transform to do if any before you compare it?
another issue is do you validate or merely check the value of the ns
attribute? if we do do a transformation we have a problem because XML
Namespaces doesn't do it! If they use UTF-8%, they can use Kanji and they
don't have to do a transformation before the comparison but I prefer to
compare exactly as it is
Makoto: do you really want to validate URIs?
James: it allows relative URIs but I don't know if is requires a transform
Makoto: I don't want to allow relative URIs...I hate them and I hate
fragment identifiers
James: do we want RELAX NG implementations to parse them and generate and
error? RELAX NG must accept strings but we could recommend that they use
absolute URIs, anything but relative URIs
Makoto: implementations are not forced to check the URI?
James: we could give a warning
James: this gives us a freer hand when checking base type libararies, we
only have to compare datatype libraries against each other
Mike: zzzzzzzzzzzzzz
James: we could do it in the form of UTF-8%
Makoto: are you half parsing it, not really parsing it then?
James: implementations do the UTF-8%
Makoto: what about case sensitive URIs [looked up section 3.1 of RFC 2396]
oh, only the scheme names are not case sensitive
James: I think UTF-8% is the right thing to do, agree with Makoto, recommend
that they validate, do not have to validate fragment identifiers, don't
require implementations to check them

Need further discussion to resolve this.

6. Restriction on <interleave> (issue 40).
7. Further restriction on <oneOrMore> pattern (issue 45).
8. Context information for datatype libraries (issue 32).

We did not discuss agenda items 6, 7, and 8.

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

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

Powered by eList eXpress LLC