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: [relax-ng] Some ideas about simple type assignment

> > I would suggest that we use collections of path-datatype pairs
> > together wth RELAX NG Schemas.  Here is an example of such a
> > collection
> >
> >
> > @a       int
> > a/@b     int
> > a/b/c    float
> > a/b/c/@d  short
> The problem I see with this is that it creates extra work for the user.  In
> most cases, the collection of path-datatype pairs is implicit in the schema.
> If a user has specified in the schema:
>  <attribute name="a"><data type="int"/></attribute>
> why do we need to force them to specify
> @a    int
> ?

Because most programmers would like to use such additional descriptions  
rather than schemas.  However, it would be certainly very nice if the (@a, int) 
pair can be generated from the schema.  In this case, it is certainly possible.

If we do not use any descriptions other than schemas, those programs which 
perform simple type assignment have to analyze schemas.  That will be very 
hard for most people.  As a result, only validators would be able to do 
type assignment.  I think that separation of simple type assignment and validation 
is very important.

> > It is possible to slightly extend this by allowing "//"
> > everywhere, for example.  But I think that fixed paths are good
> > enough
> It's very common for schemas to have elements which allow arbitrary
> well-formed XML.  For example, RELAX NG allows annotation elements to
> contain arbitrary XML.  I'm not sure what criterion you have in mind for an
> assetion's being correct wrt a schema, but using the obvious criterion, no
> simple type assertion would be correct wrt to such a schema.

For such schemas, the framework I suggested does not work.  I think that 
allowing arbitrary well-formed XML is a bad idea.  Only foreign-namespace 
elements should be allowed.



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

Powered by eList eXpress LLC