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] Motivation for restrictions in section 7.2

On Fri, 2002-07-05 at 17:09, MURATA Makoto (FAMILY Given) wrote:
> > I don't see where there is any confusion in the interpretation of the
> > examples you gave if we stick to these definitions.
> It appears that I have misunderstood this issue!
> I can think of two reasons.  First, as a principle, RELAX NG prohibits 
> those patterns which cannot be satisfied by any documents.  This principle 
> is proposed by my following mail:
> http://lists.oasis-open.org/archives/relax-ng/200106/msg00127.html
> This principle prohibits <group><data .../><data .../></group>, but 
> does not prohibit<group><data .../><element .../></group>.

Yes, that's what I meant.
> Second,  I think that users will be confused if we allow consecutive 
> <data>.  For example, people would expect that <foo>1 2</foo> matches 
> element foo {xsd:short, xsd:short}.  There is no point in allowing such 
> meaningless patterns.

Agreed, a list is the only context where it makes sense because the
string has been split.

> >  I think it's fundamentally wrong for a particular element to
> > simultaneously have as children typed content (ie something that matches
> > <data>) and elements, eg
> James also wrote:
> > 
> > <foo>123<bar/></foo>
> > 
> > where 123 matches <data type="int"/> rather than <text/>. This is the same
> > reason why I want a stronger restriction than you on mixing elements and
> > data.
> http://lists.oasis-open.org/archives/relax-ng/200106/msg00139.html 

I have more than mixed feelings about this :-)

First a case has been posted the other day on xml-dev which doesn't look
that awfull. Why is <length>2<unit>cm</unit></lenght> worse than the
classical <length unit="cm">2</length> ?

Second, I don't think that it should be the job of a schema language to
enforce good practices. Actually it's one of the things I hate about WXS
when they say for instance that unordored content models are bad

In the case of WXS it's mostly an excuse to hide restrictions and I am
puzzled to see that Relax NG is actually adding complexity to its model
and algorithm to enforce a specific practice considered as bad! Without
this restriction, the text pattern could have been simplified into
zeroOrMore data patterns with a type token and the whole stuff been
easier to implement. 

There are other practices which can probably be considered as as bad as
this one, why not enforce them? or why enforce this one in the schema
language itself.

It could be a good idea to develop something above Relax NG to measure
the quality of a schema. It could even be fun and bad practices could be
detected and reported, but again, I don't think that's the job of the
schema language itself.

Sorry for this rant which I should have expressed when it was still time
(unfortunately I was busy with my WXS book at that time) and thanks for
your patient answers.

> -- 
> MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
See you in San Diego.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema

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

Powered by eList eXpress LLC