Hi Noah,
It is not necessary to modify the
existing official XML Schema provided for SOAP by W3C. I think the
purpose of the example in the tutorial was to emphasize on the
necessity to avoid ambiguity when using <anyName>, not to show the one
and only way of doing things.
For example, it is possible to write a RELAX NG schema that would validate interesting elements (such as purchaseOrder in your example) within whatever container vocabulary(soap in your example), except the vocabulary of the interesting elements; the interesting elements can be defined in this schema or another one:
The document can be validated against
the official SOAP schema for the container structure and against
the other schema for the content. If one of the validations fails,
the document is not valid.
Greetings,
Radu Cernuta
I'm not a RELAX NG expert, but I am interested in this question, so maybe
your or other experts can provide a bit more detail. What I see at
http://relaxng.org/tutorial-20011203.html#IDAFLZR gives some of what I
think people look for in W3C Schema lax validation, but not quite all of
it. The difference I think I see is in the case where the attribute that
does have a declaration (xml:space in the example at the link) gets its
declaration from a separate schema document (in W3C Schema terms), perhaps
for a different targetNamespace. The RELAX NG solution shown seems to
require that a list of the elements to be validated be provided with the
<anyName> wildcard in an <except> element.
Consider a SOAP envelope:
<soap:envelope>
<soap:body>
<po:purchaseOrder>
...
</po:purchaseOrder>
</soap:body>
</soap:envelope>
There are a variety of ways to acheive different effects using W3C XML
Schema, but the schema that's officially published by W3C for the envelope
has the body marked <any processContents="lax"/>. If someone comes along
and writes a completely separate schema document describing the
po:purchaseOrder, and passes both schema documents in on the API call to
the validator, the envelope and the purchaseOrder will be validated
together, and the overall envelope will be marked invalid if either the
envelope markup or the purchaseOrder is in error. As I understand the
solution proposed above, it would involve modifying the W3C-provided
envelope schema to list <po:purchaseOrder> in an <except>.
Does RELAX NG have another approach, or is this considered a non-goal?
Certainly one always has the option of validating the container and the
payload separately. Thanks!
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
"Radu Cernuta" <radu.cernuta@gmail.com>
02/06/2007 06:49 AM
To: "Jeff Lowery" <jlowery@myrio.com>
cc: xml-dev@lists.xml.org, (bcc: Noah
Mendelsohn/Cambridge/IBM)
Subject: Re: [xml-dev] RELAX NG equivalent of <xsd:any
processContents="lax">?
For lax validation in RELAX NG you could take a look at the RELAX NG
Tutorial by James Clark and Murata Makoto. Section 11 (Name Classes)
handles this issue.
http://relaxng.org/tutorial-20011203.html#IDAFLZR
Greetings,
Radu Cernuta
2007/2/6, Jeff Lowery <jlowery@myrio.com>:
This has got to be a FAQ, but no luck with googling:
Trying to find a shorthand method to validate content using lax
constraints in RELAX NG. I want something like this:
#=================
namespace foo = "http://www.w3.org/foo"
qux =
element baz {empty} # some element
bar =
element bar { anyLax* } #allow baz, bar, anyOtherElement
anyOtherElement =
element * - foo:* { # any elements not in this namespace
attribute * { text }*,
(text
| anyOtherElement)*
}
anyLax = (
grammar {*} #all patterns
)*
#===========
Don't work, though.
Only examples I've seen enumerate all the grammars by name in the
schema. Doesn't appear there is wildcard of that type.
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php