[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: concur
I may have missed something or may have implemented it inefficiently but I had no problem implementing concur. James > -----Original Message----- > From: James Tauber [mailto:jtauber@bowstreet.com] > Sent: Thursday, March 15, 2001 2:51 PM > To: TREX Discussion List > Subject: RE: concur > > > The main reason I haven't implemented it is that I've been > ordering features > according to the tutorial. > > Before I read James Clark's email, I hadn't thought I'd have > any trouble > implementing it. Now I'm getting worried :-) > > I'll try it over the next couple of days and report back. > > James > > > -----Original Message----- > > From: Michael Fitzgerald [mailto:mike@wyeast.net] > > Sent: Wednesday, March 14, 2001 7:35 PM > > To: TREX Discussion List > > Subject: RE: concur > > > > > > 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 > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC