RE: concur

[Michael Fitzgerald <mike@wyeast.net>]

It seems that <concur> reaches the Plimsoll mark. If it's tough to
implement, e.g. if James Clark hasn't implemented it in his Java
implementation (is it called JTREX?), nor James Tauber in his Python
version, why not shelve it until 1.1? I mean, is it more nontrivial than
urgent? If it has no analogue in, say, SGML, then it is innovative and
experimental. Would <concur> benefit only 20% of TREX users out of the
chute? If simplicity prevails over coolness in the first version of TREX, we
could all just RELAX...oops...I mean we could let <concur> find its way into
a more mature version of the language. Informally, I agree that we (or jjc!)
should take it off the heat and put it in the fridge for a while.

-Mike

> -----Original Message-----
> From: James Clark [mailto:jjc@jclark.com]
> Sent: Tuesday, March 13, 2001 7:48 PM
> To: TREX Discussion List
> Subject: concur
>
>
> How do people feel about the "concur" element?  I'm having some doubts
> about whether it's a good idea to include it.
>
> - It's probably the most experimental feature of TREX, and standards
> aren't the place for experiments.  Almost everything else in TREX has
> some analogue in at least one other spec.
>
> - We're trying to be minimalist: "concur" I think is on the wrong side
> of the 80/20 divide.
>
> - It's quite tricky to implement (especially getting coherent error
> messages).
>
> - I think people will want to layer type assignment on top of TREX.
> It's hard to make type assignment work for concur.
>
> - Other schema languages don't have concur or anything like it, so TREX
> patterns that use concur will be hard to translate into other schema
> langauges.
>
> - The most useful application of concur seems to me to be exclusions;
> but it would be easy to add explicit support for exclusions (I'll
> address this in a subsequent message).
>
> James
>
>
>