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: Issue: overlapping with XML Schema Part 2

> > I believe the concept of restriction in XML Schema Part 2 is broken.
> > only way of treating XML Schema Part 2 facets that I have been able to
> > that isn't broken is to treat them as parameters.  If facets are just
> > parameters, what would derivation mean?
> I agree that restriction in XML Schema Part 2 has problems.  You are not
> opposing to assigning a name to a datatype combined with some parameters.
> I right?

I certainly have no problem with

<define name="percentage">
   <data type="xsd:int">
        <param name="maxInclusive">100</param>

What's harder is if you want to add more parameters to a user-defined
combination of a datatype with parameters.  I can see this would be useful,
but I don't yet see a design that I'm comfortable with.

> James Clark wrote:
> > <data type="xsd:int">
> >    <choice>
> >       <value>1</value>
> >       <value>2</value>
> >     </choice>
> > </data>
> Is this <choice> a constraint on value spaces (and then lexical spaces)?

I'm not sure we need the concept of "value space".  We can simply say that
data types define an equivalence relation on strings, eg the data type
xsd:int defines "1" to be "01" equivalent.  Within a <data> element,
comparison with <value>s would use the equivalence relation of the <data>


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

Powered by eList eXpress LLC