[xsd-users] warning with any

[Rizzuto, Raymond]

Boris,

I played around with ##any with the cxx-parser, and see that I get a
similar error:

xsd.exe cxx-parser simple.xsd
simple.xsd:39:88: warning: namespace '##any' allows for element 'diary'
simple.xsd:39:88: warning: generated code may not associate element
'diary' correctly if it appears in place of this wildcard
simple.xsd:38:29: info: element 'diary' is defined here
simple.xsd:39:88: info: turn on validation to ensure correct association

However, no error is generated with either of these command lines:

xsd.exe cxx-parser --xml-parser expat simple.xsd
xsd.exe cxx-parser --generate-validation simple.xsd

I don't know if there is sufficient demand for it, but having an option
(like --generate-validation for the cxx-tree) to generate a "perfect"
parser would address this case, albeit probably with a performance hit.

Ray

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com]
Sent: Wednesday, July 02, 2008 11:57 AM
To: Rizzuto, Raymond
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] warning with any

Hi Ray,

Rizzuto, Raymond <Raymond.Rizzuto at sig.com> writes:


> I can see where the ambiguity would occur in certain cases, such as
with
> optional or sets, but for a sequence of A, B, ##ANY, where A and B
must
> appear exactly 1 time, an A or B in the ##ANY slot shouldn't be
> ambiguous.

It is not in the XML Schema sense. It is, however, in the case of the
XSD-generated parsing code. Since XML Schema validation is performed in
the underlying XML parser we try to make the parsing code as small as
possible. As a result, it is a simple loop that iterates over elements
and tries to match them in order of appearance. In your original
example,
you have an optional element 'ticket' followed by required element
'price'
which is following by the wildcard. In the content like this:

<price>
<ticket>

The 'ticket' element should be matched by the wildcard but the generated
parsing code will match it to the 'ticket' element which is missing in
the content.

In this particular situation the loop-based approach does not appear
to be simpler than the alternative that would parser each element at
a time and then move to the next one. Things, however, get more
complex once you need to handle nested choice/sequence compositors.


> Does the warning occur for ##ANY, regardless of that?  I.e. the
warning
> is not taking the context into consideration, just telling the author
to
> be advised?

No, the compiler only issues the warning when the mis-match can actually
occur.


> Since I am not the schema author, I can't really make changes, but
I'll
> raise the question with the author.  I believe he has the ##ANY in so
> that a future version of the protocol will be compatible with the
> current version.  I.e. a 1.3 version with a new field added at the end
> of the sequence will still talk to the 1.2 version I am coding.

In this case I would assume that the 'ticket' and 'price' elements
cannot
appear in place of the wildcard in version 1.3 and thus the warning can
be
safely ignored (this is probably the case in 99.9% of the situations
this
warning is issued).

Boris

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.