[relax-ng] RELAX NG TC meeting 2002-10-31 (fwd)

[James Clark <jjc@jclark.com>]

---------- Forwarded Message ----------
Date: 02 November 2002 10:13 -0800
From: Michael Fitzgerald <michael@fitzgerald.name>
To: jjc@jclark.com
Subject: RELAX NG TC meeting 2002-10-31

[please forward to list. thanks -Mike]

Minutes for a RELAX NG TC meeting held Thursday, 31 October
2002 at 9:00 am EST (UTC -04:00)

Next meeting in two weeks: 14 Nov 2002

Present

David
James
John
Josh
Kohsuke
Makoto
Mike

Norm absent with regrests

Agenda

Issue 24

Confirmed that this issue is closed with the requirement of
## + for documentation elements

Issue 23

Confirmed closed, with the requirement to add a top-level
body production containing one element

Issue 21

Confirmed closed, allowing renaming and reordering for non-
structure preserving translators

Attribute vs. current grammar (A.1 of spec)

Makoto: I agree that we need a change
James: I agree that we need more information to help
programmers, types of arguments and return values
Makoto: The hardest part is annotations, not sure how to make
them clearer
James: Annotations are trickiest
Makoto: Need names and types
James: Need names for arguments and return values
Kohsuke: This can help, but people need to understand that
args and return values are not the grammar
James: I agree that we need more information to describe
types; we can have names or positions; we have positions in
my current syntax; names pass inherited information, this is
less evident in positions
James: should we have synthesized (single) return value or
multiple named return values? I see two possibilities: 1) an
anonymous value 2) a single names values
Makoto: this is terse, multiple types can be expressed with
attributes, elements, and strings
James: If only one or two, it is not useful to have named
return values; it would be weird and unfamiliar to
programmers to have more than one anonymous return values
Makoto: we call it a pair
James: we don't want it to be too artificial
Kohsuke: Change "pair" to something else
James: the content of an element is set to an attribute, has
subtype relationship; we should declare a hierarchy of types -
- this would be clearer
Makoto: a string is a subtype of that?
James: Yes...what do people feel: a single anonymous return
value, or multiple, named return values
David: I prefer a single anon return value
Kohsuke: Can live with it both ways
Makoto: I can live with both, but prefer multiple named
James: I can go both ways
Mike: Abstain
John: No view
Josh: Lean towards single anonymous, but not a big deal to do
the other...not quite sure
Makoto: People will want to look at a draft of this before we
decide
James: It may not be trivial to show it both ways
Makoto: If you address the lack of type information, I can
live with your notation
James: Perhaps I could do a version and then Makoto could a
version
Kohsuke: I like to be able to click on a name and jump to the
spot in the grammar
James: Yes, we can do that; type information will help deal
with built-in functions, too

James to do a version with single anonymous return value
Makoto then to do a version with multiple, named return values

Makoto: Did we change "context" to "environment"?
James: Yes...have we addressed all your issues Makoto?
Makoto: Yes
James: When we pas names, Makoto uses {}, I use () on the
nonterminal
John: Couldn't you just pass it down by default?
James: That's an interesting idea; could pass down
environment [?] args by default, others passed down by name;
makes environment args [less cluttered] which is good; terse
but less obvious
John: Explicitness is not a virtue when it crowds out the
obvious <= quote of the week
James: Wise words...I'll apply John's principle, use XSLT to
do both default and passed down...what about {}?
Makoto: {} is closer to attribute grammar, stuff that can be
ignored; on the other hand, I have mixed feelings
James: I have mixed feelings as well
Kohsuke: {} are sort of ugly, I like () [?]
James: () after nonterminal move to {} after each attribute?
Josh: {} closer to parser generator format
James: Yes...what does yacc do?
John: yacc does $n
David: isn't this just a question of style?
James: I'll try to do both in my XSLT to see what turns out
Mike: this is our only remaining issue [finalizing the
attribute grammar] before we are done ? [go to committee spec]
James: Yes
Makoto: I'd would be nice to be done for XML2002! [Dec 8-13]
Mike
==================
Michael Fitzgerald
Wy'east Communications
mailto:mike@wyeast.net
http://www.wyeast.net



---------- End Forwarded Message ----------