[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] Present: 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 1.0. 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 it. 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 1.0. 8. Versioning strawman. Will use the namespace versioning model as James proposed in his strawman. http://lists.oasis-open.org/archives/trex/200104/msg00052.html 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!! 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