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: Datatype interface extension

> Are you saying that the allowed arguments of the isValid() method on the 
> Datatype interface depends on the return value of the isContextDependent() 
> method on a separate interface? That doesn't seem right to me. The Datatype 
> interface should be semantically self-contained.  I think the 
> isContextDependent() method must be on the Datatype interface.  This isn't 
> so bad, as it's potentially useful for other applications independently of 
> the Datatype compatibility spec. The getIdType() can be on a separate 
> CompatibilityDatatype interface.

Then I think it's OK to have all methods (including getIdType()) on the
Datatype interface.

Implementing the getIdType() method is easy (just return ID_TYPE_NULL)
and so it's very easy for datatype libraries to support it.

If they are separate, processors need type checking and casting to call
the getIdType method. I guess less optional features are better.

We've added the createStreamingValidator method, which is arguably an
optional feature, into the Datatype interface. So I think it's OK to
treat the getIdType method in a similar way.

Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@sun.com

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

Powered by eList eXpress LLC