[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Datatypes
James Clark wrote: > > > If we can assume that parameters never change the equivalence relation, > > we can always compare the base type name > > I don't think we can assume this. The whiteSpace facet changes the > equivalence relation. You are right. > > All it requires is that the library provide a service that says what the > type of each of the parameters is, or a service that comparese to parameter > sets of equality. > > That's doesn't seem hard to me. This doesn't look easy to me. It will take more than a day for me to implement it. Furthermore, I do not think that existing implementations of XML Schema Part 2 provide such services. > Alternatively we can just compare the > values as strings. That's not so bad, so long as we don't use parameters > for enumerations (which would cause a problem with QNames). I think that this is worse than prohibiting anonymous datatypes for keys. One question: does SQL allow anonymous datatypes for keys? I tried to find an answer today, but I couldn't. Jonathan? > > I don't like replace (Issue 20). > > > > > http://lists.oasis-open.org/archives/trex/200105/msg00120.html#orderSignific > ance > > Do you have an alternative solution that handles XHTML modularization? <note>I owe very much to Kawaguchi-san about this.</note> In your rewrite of XHTML modularization, you use "replace" as follows: form.trex:<define name="form" combine="replace"> form.trex:<define name="select" combine="replace"> frames.trex:<define name="html" combine="replace"> table.trex:<define name="table" combine="replace"> table.trex:<define name="th" combine="replace"> table.trex:<define name="td" combine="replace"> table.trex:<define name="CellHAlign.attrib" combine="replace"> table.trex:<define name="CellVAlign.attrib" combine="replace"> table.trex:<define name="scope.attrib" combine="replace"> RELAX allows more than one <elementRule> per label, just like a regular grammar can have more than one production rule per non-terminal. If we allow more than one <define> per name, we can cover the first five cases. The remaining three cases can be covered by my proposal as below: > On the other hand, I think that it should be possible to add > values to a list of allowed values (specifed by <enum>). > > I also think that patterns for hedges and datatypes for > > whitespace-separated lists are different beasts. > > Any particular reason? I haven't reached a view on this one yet. It is > interesting that XML Schema Formal Description uses the same construct for > both. Suppose you receive SAX events such that text chunks are concatenated wherever possible. No other mechanisms in TREX require division of such text chunks during validation. Only this mechanism requires division of such text chunks. > How (if at all) would you specify the allowed min/max length of the list? If this is really necessary, we only have to introduce two attributes. How would you allow two-dimensional vectors? Cheers, Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC