- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Fri, 6 Nov 2009 17:35:19 -0700
- To: kennardconsulting <richard@kennardconsulting.com>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, xmlschema-dev@w3.org
On 5 Nov 2009, at 23:58 , kennardconsulting wrote: > > I'm generating a bunch of XML Schemas that look roughly like: > > <xs:schema ...> > <xs:element name="foo"/> > <xs:element name="bar"/> > </xs:schema> > > You can see the actual ones http://metawidget.org/xsd here . My > question > is, this schema allows me to declare 'foo' and 'bar' in my XML > document, but > doesn't restrict me declaring, say, 'baz'. I'm not quite sure what you're saying. Where I come from, it is natural to speak of declaring 'foo' and 'bar' elements in a schema document (as is done in the skeleton you give), but odd to speak of 'declaring' elements in the XML instance being validated. If you mean "how do I prevent someone else writing a schema document for my target namespace and including a top-level baz element in it?", the answer is that you can't prevent other people from writing what they like in documents on their own hard disks. The world is just structured that way. On the other hand, you don't have to use the schema documents on their hard disks when you validate. If you want to ensure that in a particular validation episode 'foo' and 'bar' will be global elements in the target namespace, and 'baz' won't be, you just need to arrange with your schema validator, at invocation time, that it should read your schema documents, and not the ones on other people's disks that include declaration for 'baz'. How you arrange with a validator to read certain schema documents and not read others is out of scope of the schema language itself; if a particular validator does not allow you to control things with the degree of precision you need, it's a quality issue and you should look for a new validator. If on the other hand you mean "how do I keep someone from using a 'baz' element in my namespace?", again, the universe is so structured that nothing you or XSD or any other schema language can do could possibly prevent that. The most you can do is try to arrange that such a usage counts as invalid when the document is validated against your schema. So consider the question "how do I ensure that when a user uses a 'baz' element in my namespace, it's marked invalid?" The answer is, roughly: (a) tell the validator to read your schema document and not some bogus one which defines 'baz' (see above); (b) make sure your processor distinguishes between elements with [validity]=invalid and those with [validity]=notKnown (again, how you do this is between you and your processor, and out of scope for the XSD spec); and (c) make sure your own code that invokes the validator rejects the cases where [validity]=notKnown. > I was expecting something like... > > <xs:schema final="#all"> > > ....so that I could 'close' the set of possible xs:element names. Or > maybe > that the set was closed by default and I'd need... > > <xs:schema ...> > <xs:element name="foo"/> > <xs:element name="bar"/> > <xs:any /> > </xs:schema> > > ....to make it open. But instead the set of top-level xs:element names > appears 'open' by default and I can't find a way to close it? I have > looked > all over the specs and in this forum, sorry if I'm being dumb. I'm not sure what you mean by open and closed sets of elements (or element names) here. I'm also not sure whether by "top-level" you mean "can be used as the root element of a document" or "defined on the top level of a schema document; not local to a complex type". But in a way, I guess, it doesn't really matter: XSD's design says, essentially, that the way you specify "these declarations, and no others" is to say just that, but at validation time, not at schema specification time. I hope this helps. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Saturday, 7 November 2009 00:35:51 UTC