[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) Attendees James Makoto Kohsuke Mike Not Attending Norm Fabio Josh David 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: http://lists.oasis-open.org/archives/relax-ng/200107/msg00211.html 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. Mike ==== 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