[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes for RELAX NG TC meeting 2001-07-26
Minutes for the RELAX NG TC meeting held July 26, 2001, 10:30 am EDT (UTC -04:00) Attendees James Makoto Kohsuke Josh David Mike Not Attending Norm with regrets Fabio with regrets Next meeting: Thursday, August 2, 2001, 10:30 am EDT (UTC -04:00) 1. Processing of datatype library and ns attributes (issue 47). James: we already support validation of the href attribute of <include> and <externalRef> and that there would be an inconsistency if we did not likewise validate the value of the datatypeLibrary attribute, some checking is reasonable to do. Kohsuke: a URL is easier to check than a URI. Makoto: what if the value of datatypeLibrary was not known to the processor? James: some generic checking is necessary, for example, there must be a legal scheme name [such as http://]. Makoto: is there scheme specific checking in XML schema? James: no, generic only, and it's not very clear. We should not force people to read the pertinent RFCs [2396, 2732] as they are not likely to come up with the same answer! James: absolute URIs are easy to check, for example, never right to have two hash (#) marks. Could provide a regular expression showing how we will check URIs. Makoto: you are proposing not to use 2396, 2732? James: they are too round about Makoto: you are then going to provide an interpretation of 2396? James: not an interpretation; 2396 is not enabled to do generic checking! We could say, "Here are the aspects [of the URI] that we require you to check. If 2396 were perfect, we could say "just do what 2396 says" but it's hard to figure out and we don't want to [spawn conflicting interpretations]. We could say "do a 2396 conformant implementation and [here is a handy] regex [for generic checking]. We need to provide them something concrete. TC closed the issue. Action: add note to spec about our implementation approach, add regex. 2. Restriction on interleave (issue 40). Makoto: Place a pointer to the e-mail archive to mail on this issue. TC approved of noting this issue [potential combinatorial explosion!] in the spec. 3. Further restriction on oneOrMore (issue 45) Makoto: this is my proposal. I am trying to make the BNF simpler. James: probably we are presenting 6.1 in the wrong way? Makoto: I want to make everything simpler. James: if the BNF is difficult, perhaps we could provide multiple, simple grammars? I don't want to forbid something natural. [David Webber joined at this point] James: we could group the productions, with prose between, it will take some XSLT hacking James: we could leave this issue open with a note in the spec Makoto: that would be great, let's restructure and wait for more input This issue remains open with the action of restructuring the BNF and adding a note to the spec. 4. Context information for datatype libraries (issue 32) James: do we want to add anything more about context information? Kohsuke: No. [Does this close the issue? -mjf] 5. New issues. Makoto: add more examples James: let's just do that; it doesn't need to be an issue Makoto: issue: whitespace strings of a datatype, don't validate two space characters [e.g.] if the param indicated a length of two and the type is string! TC approved to add it as an issue. Kohsuke: issue: unknown datatype libraries. James: broaden this so that in order to conform you must be able determine if it is a correct datatype library, but what should we say about knowing all datatype libraries? Kohsuke: it's a strong motivation to not have your own library! James: we don't want to discourage people from using XML Schema datatype library David: what about ebXML style registry for discovery of datatype libraries? TC: okay as an issue. Kohsuke: issue: <notAllowed/> as name class. Nice to have when converting from other schemas. James: name classes affect only elements and attributes Makoto: we should only use it for internal purposes, not for user level. James: we use <notAllowed/> now to help redefine and combine patterns. Kohsuke: it will make the BNF easier... Makoto: I don't buy that argument. TC did not approve this new issue. James: issue: rename key/keyRef. XML Schema is doing something more sophisticated [than we will offer at first], it's more like ID/IDREF as it stands Makoto: I'd rather have <list> with <key> TC did not approve of this new issue. 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