W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2007

RE: Permit (greedy) conflicting wildcards

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 10 Apr 2007 15:04:05 -0400
To: "Michael Kay" <mike@saxonica.com>
Cc: "'Michael Kay'" <mike@saxonica.com>, "'Pete Cordell'" <petexmldev@tech-know-ware.com>, xmlschema-dev@w3.org
Message-ID: <OF6D990F18.01E8E021-ON852572B9.00680DEA-852572B9.00688CC8@lotus.com>

> Replying to myself, there is actually another approach, which is to 
allow
> the schema to change, and to automatically recompile queries whose
> assumptions about the schema have become out of date. Saxon 
> actually does a
> bit of that too, in a small way. 

That seems like an appropriate strategy to me.

> But you wouldn't want to take this to extremes, for example by 
> not reporting
> static errors in the query on the off-chance that by the time 
> the query is
> executed, the schema will have changed sufficiently to make the
> query valid.

It seems to me that such "errors" should in fact be considered warnings at 
compile time, and as real "errors" only if they remain at runtime. 

> Reporting static errors in a query at run-time because changes 
> to the schema
> have made the query invalid is also rather unsatisfactory, because 
you're
> reporting the error to the person running the query and not to the 
person
> who wrote it (or to the person who changed the schema).

Well, you can freeze the schema as early or as late as you want.  If you 
want to be sure there are no runtime errors, then you need to make sure 
nothing of concern changes between the time you check and the time you 
run.  Schema as a language does nothing to prohibit your ensuring such 
lack of late changes.

What I'm reluctant to do is to start introducing constraints that apply 
across multiple "schemas", in the sense of a set of components that 
collectively satisfy the constraints on components, and are thus what's 
required for a validation episode.  By my reading (though I know MSM would 
prefer it otherwise), the spec provides a definition of what is and is not 
a legal schema.  It does not say explicitly anything about how piece parts 
of such schemas might reappear in other schemas.  I think it's simpler and 
in a sense more powerful that way, but it does mean that you have to do a 
certain amount of late binding, or late checking, or ensuring that not 
much changes after you do checking, if you want to implement the sort of 
compiled component sharing you're looking for in Saxon.  At least, that's 
my reading. 

Noah


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Tuesday, 10 April 2007 19:04:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:59 GMT