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: TREX TC Minutes 2001-05-03

TREX TC Minutes for 2001-05-03 10:30 AM EDT

[Please post corrections/amendments with replies to TREX list. -mjf]


James Clark
Kawaguchi Kohsuke
Murata Makoto
Mike Smith
Josh Lubell
Mike Fitzgerald

Not Present:

Eric van der Vlist
James Tauber
Fabio Arciniegas
Don Smith

Next Meeting: Thursday, May 17, 2001, 10:30 EDT (UTC -05:00 or +07:00)

1. ID/IDREF in attributes only?: Agreed that both elements and attributes
should be permitted to have datatypes of ID/IDREF rather than just
attributes, as in XML 1.0.

2. ID/IDREF as XML Names only?: Agreed to not limit ID/IDREF to Names only.
They can also be strings (contain spaces) and start with numbers, etc.

3. IDREFS support? IDREFS in XML 1.0 are a white-space separated list of IDs
in attribute values only. Agreed that there was not a great need for this in

4. Typed Keys. Shall we allow typed keys? Not just strings but any datatype?
K.-san  - yes; M.-san - very useful; James - of two minds. We will not do
what XML Schema does in that it permits typed keys of different types to be
equal, that is, int 1 == float 1.0. Another issue is that a key of type int
means that 1 == 01 and will be considered a duplicate key. James - if we do
it, we do it, but must be same datatype!

5. Multiple symbols spaces. Shall we provide the capability to have symbol
tables of IDs, such as SSNs, VINs, etc. James - easy to support; K.-san -
nice to have. We agreed to include in 1.0. James - most real documents need

6. Multi-part keys. Shall we provide support for multi-part keys in 1.0?
M.-san - used in databases; James - could use something like Schematron on
top to add constraints; James - better left after 1.0; M.-san - I am a
minimalist about constraints; K.-san - avoid if we can; James - could be
done in schema or with a different language.

7. Hierarchical scoped references. A VIN database could have subelements for
State, then State code, then regno, etc., items then can be
scoped/referenced in this hierarchy. James - symbols spaces [5 above] are
scoped to document. M.-san - let's talk about by mail. James - I don't want
too many levels of the language, want to keep it simple. Will not do for

8. Versioning strawman. Will use the namespace versioning model as James
proposed in his strawman.

9. Repeat M-N times. James - on border line. K.-san - border line too.
M.-san - avoid in 1.0. Josh - for it. Can we limit to small cardinality? Can
we leave cardinality up to implementation? James - then what about
interoperability? Josh - highly desirable but can live without. James - when
in doubt, leave it out, but too few people in this call, we say no
tentatively, but others can object, predict it in 2.0, XML Schema defaulting
[of minOccurs/maxOccurs] is not clear but if in an attribute, it is clear.

10. Name change. James - blending of Relax/TREX name hard to do, but we
don't want a completely new name [because it would suggest a proliferation
of schema languages which we don't want]. James - I think we should go with
Relax 2.0 or some adjective [or tag], don't like what "2.0" suggests though.
M.-san - I like this. It will be easier to advance JIS/ISO specs. Josh -
Relax .NET? K.-san - Relax++? James - Relax NG [Next Generation]?

ACTION: Think about the spec and how we will go about writing it or using
the tutorial and spec material we already have.
ACTION: Think about a new teleconferencing service!!

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