Schema instance documents

[Ray Plante]

Hey Matthew,

On Tue, 29 Jun 2004, Matthew Graham wrote:
> Some changes that would help are: 
> - use of nillable, both for attributes and elements
> - default values are specified for all enumerations
> 
> Of course, I could also amend my stylesheets to insert meaningful null
> values where needed but I would like to have the discussion about whether
> the schema should define nillable and default values extensively first.

Hmm.  Obviously, this would affect what is valid for records to be 
considered complete and exchanged interoperably between systems.  That is, 
it allows resource records, for example, to not provide required 
information by providing xsi:nil="true".  

(BTW, I don't thing you make attributes nillable.)

Default values have definite meaning for consumers: if the value is not 
provide, the value is to be taken to be the default one; the meaning of 
the default value applies.  If a default is not provided, the intended 
meaning is application specific (the equivalent to DTD's #implied).  In 
the case of VOResource, when an enumerated value is not supplied, the 
general meaning is that either the appropriate value is not 
known/available or none of the allowed values apply.  To support this 
implied meaning, we would have to define a "not available" value of some 
sort.  

BTW, default values for elements are handled differently for elements 
compared to attributes; I'm not sure this would solve your problem.  
Further complicating things, some VOResource elements of enumerated types, 
like VOResource's "Type" and "ContentLevel", can have several (or no) 
values. 

One way to deal with this is through a local, modified version of the 
schema.  This is perhaps less desirable because it makes it harder to 
support an arbitrary schema.  Would a simple filtering of the schema 
with in your app to effect these changes be practical?

cheers,
Ray