- From: <noah_mendelsohn@us.ibm.com>
- Date: Thu, 30 Jan 2003 08:47:12 -0500
- To: "Hanna" <lhnhanna@hotmail.com>
- Cc: lhnhanna@hotmail.com, xmlschema-dev@w3.org
Thank you for taking the trouble to notice my earlier note on this subject. I think your current question boils down to: Q. Is there any way to provide schema declarations for elements, attributes etc. that are in more than one namespace, using just a single XML (I.e. XSD file)? A. Short answer: no. Longer answer: yes, in principle, but not in a way that has been standardized The schema recommendation carefully separates the definition of the standard for the core capabilities of the language from the definition of the syntax of the schema documents (informally called .xsd files) that are used to write down those definitions. In principle, a processor can conform to just the former, and get its definitions using more or less arbitrary means. In practice, most processors I'm aware of support only .xsd (a reasonable choice for now), and by definition an .xsd file covers at most one namespace. Indeed, even the .xsd format itself (to adopt your terminology) is specified at the Infoset (abstract elements and attributes level.) A third level of conformance is associated with retrieval of such representations in the form of XML documents using URIs and the mechanisms of the web. That's a round about way of saying that there is a conformance level governing what most processors today do: get each .xsd document from a separate "web file". Nothing in the recommendation prevents anyone else from establishing a standard for new representations, or from packaging multiple .xsd infosets together. E.g.: <newstd:schemas> <xsd:schema targetNamespace="one"> ... </xsd:schema> <xsd:schema targetNamespace="two"> ... </xsd:schema> </newstd:schemas> This would be just one way to do it. As of now, I'm not aware of any such standard, and therefore not aware of any processors that provide this capability, but the recommendation leaves room for someone to standardize this usage. Note that this flexibility in the schema recommendation is used in some other contexts. WSDL, the description language for SOAP and Web Services, embeds fragments of schemas within WSDL files using the technique described above. There are WSDL processors that extract these schemas and provide them to XML processors for use in validation. I'm not sure this is the answer you were hoping for, but I do hope it helps. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ "Hanna" <lhnhanna@hotmail.com> Sent by: xmlschema-dev-request@w3.org 01/29/03 10:44 PM To: <xmlschema-dev@w3.org>, <lhnhanna@hotmail.com> cc: (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: RE: XML schema validation and namespaces Categories: Dear all, if i don't have xsd file to be refereced but i want to deal with multiple namspaces in schema. How can it be done? In fact, can one schema handle multiple namespace without ref or import? Please help ! Hanna -----Original Message----- From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] Sent: Friday, September 06, 2002 8:20 AM To: Sanjay Dahiya, Noida Cc: xmlschema-dev@w3.org Subject: Re: XML schema validation and namespaces Well, I can give you some general idea of how things work. First of all, you're right, there are namespaces tbat you bump into in schema documents, namespaces that the instance might use, and a set of rules that have to keep straight how these all work together. The schema design goes to great length to cover these, and it probably gives more flexibility than you'd notice at first. A schema document can use the <import> construction to refer to other schema definitions for other namespaces. Optionally, the import can supply a schemaLocation hint (and it's only a hint!) that the process MAY choose to follow to look for the schema definitions for that other namespace. Alternatively, the schema processor can use some other means to figure out what schema definitions to use for that other namespace (maybe it takes command line options, has an API, builds in definitions for certain namespaces, etc.) So, what happens if an instance document uses a namespace in some element in the middle of content: <ns1:outer xmlns:ns1="uri1"> <ns2:inner xmlns:ns2="uri2"/> </ns1:outer> What are the possibilities for where we get the definitions to validate ns2:inner (presuming we had a schema for ns1?) Well, I'm too lazy to type all the schemas exactly correctly, but if the schema for ns1 says roughly <schema targetNamespace="ur1" xmlns:ns1="uri1" xmlns:ns2="uri2"> <import namespace="ur12"> <element name="ns1:outer"> <sequence> <element ref="ns2:inner/> </sequence> </element </schema> then the processor will go looking for some schema document (or other source of definitions) for ns2:inner. Exactly how is, as described above, up to the processor. With: <schema targetNamespace="ur1" xmlns:ns1="uri1" xmlns:ns2="uri2"> <import namespace="ur12" schemaLocation="http://example.org/ns2.xsd"> <element name="ns1:outer"> <sequence> <element ref="ns2:inner/> </sequence> </element </schema> then the processor MAY chose to get those definitions from http://example.org/ns2.xsd. Another way it might get the hint is from the instance: <ns1:outer xmlns:ns1="uri1"> <ns2:inner xmlns:ns2="uri2" schemaLocation"uri2 http://example.org/ns2b.xsd"> </ns1:outer> Again, it's a hint. The processor can honor the one in the import, in the instance, neither, etc. Now consider: <schema targetNamespace="ur1" xmlns:ns1="uri1" xmlns:ns2="uri2"> <import namespace="ur12" schemaLocation="http://example.org/ns2.xsd"> <element name="ns1:outer"> <sequence> <any processContents="lax"> </sequence> </element </schema> This says that outer can have most any contents. Does ns2:inner get validated? Well, if the processor choses to find a schema, perhaps from one of the schemaLocation hints, then the inner element does get validated. "Lax" says: validate if you have an element declaration, otherwise don't worry about it. "strict" (instead of lax) means "you better have an element declaration, if not fail". "skip" means don't validate the inner element even if you could. To really understand this, you should find a good tutorial on schema, or maybe even do the hard work of reading the spec (it is hard in this area.) I hope you can see that the design provides quite a bit of power for dealing with the situations you've raised. Many of them do arise in various uses of XML. I hope this is helpful.
Received on Thursday, 30 January 2003 09:26:37 UTC