[glue-wg] [XML] some questions

[Paul Millar]

Hi all,

As I mentioned during the XML phone conference, I've a few questions about the 
current XML rendering.  I don't think they're too important (not 
show-stoppers), but they might be worth raising.

1. In the Base type we define a Validity as an int 0..1,

I suspect that this is really a boolean (which is a base-type).  In 
XML-Schema, the boolean type can be either "true", "false", "0" or "1" (with 
true/false is the canonical form).

So, if we switch this to a boolean, we would allow "true" and "false" as valid 
entries.  If we don't want this, we can contract the boolean so it only 
accepts "0" or "1" (I think), but is a boolean none-the-less.

Also, perhaps this attribute should be isValid (so something that maps more 
directly to a boolean), rather than Validity (which should take values like 
is-valid or is-not-valid).


2. XML nillable vs Validity

XML Schema allows entries to be "nillable"; that is, the corresponding point 
in the XML tree can be empty, even if has required content.  For example, 
AdminDomain has a required child element: ID.

<Grid>
	<AdminDomain>
		<ID>CNAF</ID>
		<!-- more here -->
	</AdminDomain>
</Grid>

If AdminDomain was nillable, the following

<Grid>
	<AdminDomain/>
</Grid>

would still be valid (i.e., pass the XSD validation).

The current XML Schema has nillable switched off for all elements.

Do we want to express invalid objects by simply publishing empty objects?  
Does it make sense to publish an AdminDomain with validity=false and a 
ComputingService with validity=true ?

I'm not particularly advocating this, but rather posing it as an interesting 
question.  See also (a random Google find):

http://www.stylusstudio.com/xmldev/200309/post20390.html


3.  Adding "unknown" as a place-holder enumeration value for all enumeration 
types.

Do we want to include an "unknown" (or similar) value for the enumerations?  
This would be to satisfy the two use-cases described in Appendix A.

This is perhaps not an XML-specific question, though.

Cheers,

Paul.