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 meeting 2001-07-26

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



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
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

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

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
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
Makoto: I'd rather have <list> with <key>

TC did not approve of this new issue.

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