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: 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?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC