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

Minutes for RELAX NG TC Meeting, Thursday, June 21, 2001 10:30 AM EDT
(UTC -05:00)

[Please post corrections and amendments by replying to the list. -mjf]


Mike S.
Mike F.

Not attending

David Webber

Next meeting: Thursday, June 28, 2001 10:30 AM EDT (UTC -05:00)

Issues list: http://www.oasis-open.org/committees/relax-ng/issues.html (not
always the most up to date).

1. Restrictions on string/data in pattern (issue 18). See the grammar at


which is relevant to this and subsequent issues.

TC voted to approve this. Murata-san: "I can live with it." Kawaguchi-san:
"I will not object."

Discussion from Murata-san's notes:
James: This BNF is an encoding of James' proposal encoding rather than
Kawagauchi-san's proposal.
Kawaguchi-san: I don't understand. What does "repeatable" represent?
James: oneOrMore including both elements and attributes
Makoto: I don't think Kohsuke's proposal provides any advantages. Closure
under boolean operations are not made worse or better by James's proposal.
I have a feeling that our patterns are closed under boolean operations, and
I'm writing a proof for this.
Kawaguchi-san: What about datatypes?
Makoto: Difficult. What is the intersection of <list><data
type="xsd:string"/></list> and <data type="xsd:string"/>?
Conclusion: As far as use of <data>, <value>, and <list> are concerned, we
have agreed on James' proposal.

2. Restriction on <list> in <list>.


TC agreed that it should be a syntax error to use <list> as a child of
<list>. There is no reason to allow it.

3. Should we allow <difference> in patterns but highly restricted? (Related
to closed issue 13.)


A lengthy discussion ensued. This issue was based on public comments from
Jeni Tennison. Murata-san: "I disagree." Murata-san believes that if we
generalize <not>, we should then use <not> for everything. James explained
that the use case was for limited use (strings only). James suggested that
we "think more about this comment."

Murata-san notes:
People feel that consistency between name classes and attribute values is
important. Some people feel that this feature does not hit 80-20.
Kawaguchi-san said that if we allow this, we should also allow concur
(intersection) as well.

4. If so, should we also allow <not/> in patterns?

We skipped our discussion on this item [because, I believe, we had deferred
#3 until next week -mjf].

5. Should <not/> be able to have multiple operands like <difference/> can?


>From Jeni Tennison.

TC took no action today; however, we are anticipating a rename proposal from

Murata-san's notes:
As far as the keyword is <not>, nobody wants to do that. But if the keyword
is changed to <anyValueExcept> or <allBut>,
Makoto wants that.  Makoto will raise this issue.

6. What namespace mapping should be passed to the datatype library for
interpreting the content of <value/>? Specifically, should the default
namespace come from the ns attribute or the xmlns namespace declaration?


>From Jeni Tennison.

TC agreed that the default namespace should come from the ns attribute.

7. One public comment has suggested allowing <zeroOrOne> instead of/in
addition to <optional>? A private comment to me has also suggested the same.
Do we want to do anything about this?

In the TC there was no strong feeling to change this.

Review of occurrence operators in DTDs and current RELAX NG syntax:

? (zero or one) is <optional>
* (zero or more) is <zeroOrMore>
+ (one or more> is <oneOrMore>

Murata-san notes:
Quite a few people can go either way, but somebody prefers optional. James
prefers optional.  Nobody strongly feel we should change. Consensus: no

8. Context info for type libraries (issue 32).


James proposed that we say /context/ rather than a /namespace map/. Then the
context would be guaranteed to include a mapping from prefixes to namespace
URIs but that would be it. We would leave it open-ended. James and
Murata-san had trouble clarifying this and it was suggested that either
James or Murata-san write some language that might appear in the spec and
then to post and come to agreement on the text at a later time.

Murata-san notes:
We agree that datatype library implementations will receive hidden
parameters.  Makoto thinks that we do not have to say anything about such
hidden parameters and that we should merely say that datatype library
implementations receive a prefix-URI
mapping.  Makoto (or James) will write a proposal.

9. Key/keyRef scope (issue 29).


James proposed that the key/keyRef symbol space should be identified by a
namespaceURI/local-name pair rather than merely by a local-name. This means
that we would use QNames rather than NCNames for key/keyRef.

TC agreed with James' proposal and the issue is now closed.

10. Syntax for global attribute (issue 5).


This issue was skipped and we will leave it until next week.

Murata-san's notes suggest something different:
Consensus: global="true"

[I don't believe we reached agreement on this. -mjf]

11. Organization/copyright of test cases.

Both Mike Smith and Fabio A. have had experience setting up SourceForge
projects. James said that he views test cases as software, not documents.
Mike S. stated that SourceForge allows only one license that you can't
change it, but Fabio believes this is not the case. In earlier mail, Mike S.
had suggested a different license rather than the MIT license that James had
suggested. James described the MIT license as allowing anybody to do about
anything they want! Fabio has an action item to set up the project. There
was some inconclusive discussion as to whether we will set up just one SF
project to handle conformance testing, datatype interface, and
documentation. Fabio will work on the test case project only for now.

TC agreed that we don't want this to come under the OASIS umbrella so that
we don't have to deal with the copyright issues. [I believe the feeling was
that more people could contribute to the effort this way, beyond just those
in the TC. -mjf]

Murata-san's notes:
Test cases are not our official products. Very short and simple license
should work. Fabio volunteered to create a license.

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