W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2002

Re: Should this schema be invalid?

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 5 Aug 2002 09:30:36 -0400
To: ht@cogsci.ed.ac.uk (Henry S. Thompson)
Cc: Cliff Schmidt <cschmidt@microsoft.com>, Dare Obasanjo <dareo@microsoft.com>, "'Jeni Tennison'" <jeni@jenitennison.com>, Xan Gregg <xan@tibco.com>, xmlschema-dev@w3.org
Message-ID: <OFEB521BD2.1606F9F2-ON85256C09.007B8ECD@lotus.com>

Henry Thompson writes:

>> As previously noted, I believe we can easily 
>> implement this at 'compile time' via coontent 
>> model FSM subsumption checking.

Have we proven that this is possible in all cases without combinatorial 
blow-up of the FSMs for maxOccurs = notSmallInteger?  I don't think it's 
generally acceptable, from a security and denial of service point of view, 
to have rules which have as their only practical embodiment such 
characteristics (of course, there is still the option to make compile time 
checking optional, and to allow successive validations against derived and 
parent types at run time -- that's not entirely pleasing from a 
performance point of view either, but maybe it's an out.)

In other words, if there isn't a really good way to do the subsumption at 
compile time, then I think we'd have to allow implementations to consider 
the derivation as valid until an instance arrives that actually exposes 
the error.  I don't think that's entirely desireable either.

Bottom line:  if the subsumption has no major drawbacks, and covers our 
actual grammars ({min,max}occurs, etc.), then I think I'm for it in a 
future release.  Otherwise, I think we need to proceed carefully.  It 
would be a shame to replace one impractical approach with another. Thanks!

P.S. Sorry I missed the F2F...Protocols was meeting at the same time.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Monday, 5 August 2002 09:33:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC