Guillaume,
SQC sometimes does get line numbers wrong. Sometimes it reports the
same error with 2 line numbers: one that corresponds to where the XML
element start tag with the problem started, and a second that corresponds
to where the XML element end tag was.
As to the specific messages SQC issued when run on your schema, let's
take them one at a time.
1) "1758" not of type gYear
Looks like we have a bug. Thank you for reporting this.
2) line 243 - particles overlap
When you want to take a particle that had minOccurs='0' in
its base type, and extend it to say minOccurs="1", and the particle is in
the middle of a group (in this case a sequence), I really don't know if
there is syntax in the XML Representation of W3C XML Schema to do this.
(The fact that you were also saying that the minInclusive value of year
needs to be 1758 did not enter into our analysis of this at all). The best
place to get expert advice on "how do I say this in W3C XML Schema
language" is the mailing list [EMAIL PROTECTED] .
3) <selector xpath="model:data/*/model:author"> confuses the checker.
Looks like we have a bug. Thank you for reporting this.
4) No node in element dataset corresponds to <selector xpath
="model:data/model:publications/model:publication/model:publisher"/>
SQC messages can be classed as WARNINGs or ERRORs. We put these XPath
messages as warnings in part because we are aware that if you used derived
types (and the instance document specifies they are being used via
xsi:type), the warning may not apply.
I will speak with my colleague who wrote the xpath checker, and see if
it is possible to examine derived types, and if one of them might make the
xpath valid, change the wording of the message to add "However, if the
instance document uses xsi:type to specify type foo on element bar, this
xpath would be legal". However, given that in a naive approach, we would
have to examine derived types for every particle whose type is complex,
recursively, this could be time consuming. So only if we have a few days
-- to work out an intelligent algorithm for deciding which particles with
types we should look at derived types for -- does this make sense to do, in
my opinion. Then we could actually add "However, if the instance document
uses xsi:type to specify type foo on element bar, or type foo2 on element
bar2, or type foo3 or type foo4 on element bar3, this xpath would be
legal". That would be very precise, but also risks making the message so
long that no one will want to read it.
I truly appreciate the feedback. (We say in our Readme that we are
not confident the checker is always correct. We were not overly modest :-)
). If you have additional feedback, and don't want to bother all the
readers of [EMAIL PROTECTED] (not all of whom use schema
validation), you can send e-mail directly to our 2-person SQC team at
[EMAIL PROTECTED] .
Thanks,
Bob
Bob Schloss
IBM Thomas J. Watson Research Center - Next Gen Web group
Yorktown Heights, New York USA
http://www.research.ibm.com/people/s/bschloss
http://www.research.ibm.com/XML
Guillaume Rousse <[EMAIL PROTECTED]> on 08/23/2001 02:03:21 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], "
<[EMAIL PROTECTED]/
Subject: Re: xpath error
Ainsi parlait Guillaume Rousse :
> Interesting enough, this one (sorry for the careful layout) is detected,
> but the exact same one at line 94 is not...
I could have been wrong, as some errors occuring at the beginning of the
schema are also reported at the end. However, it's curious behaviour.
Also, some others are reported at uncorrect line number:
line 70 column 92 :
"1758" is not of the type : simpleType
http://www.w3.org/2001/XMLSchema:gYear.
Here are also some kind of errors reported i would like to discuss, as they
seems curious for me:
1) "1758" not of type gYear, occuring at line 243
Message:
"1758" is not of the type : simpleType
http://www.w3.org/2001/XMLSchema:gYear.
Discussion:
Quoting specification at http://www.w3.org/TR/xmlschema-2/#gYear :
For example, to indicate 1999, one would write: 1999.
So, i disagree with this one
2) Overlapping element declaration, occuring at line 243
Message
Ambiguous content model : the following particles overlap :
In super type:
<element maxOccurs="1" minOccurs="0" name="year" type="gYear"
xmlns="http://www.w3.org/2001/XMLSchema"/>
In derived type:
<element maxOccurs="1" minOccurs="1" name="year">
<simpleType>
<restriction base="gYear">
<minInclusive value="1758"/>
</restriction>
</simpleType>
</element>
Discussion:
It was an attempt for me to derive a type by extension (adding elements),
while restricting allowed values on some of inherited elements. In this
case,
an Event can occurs anytime, but a NameCreationEvent can only occurs after
1758.
I agree it's standard OO design pattern, but not necessarily legal in XML
schema. So I think i'm wrong, but i don't know how to do it otherwise :-)
3) No corresponding element when depth is variable, occuring at line 427
and
432
Message:
No node in element http://lis.snv.jussieu.fr/~rousse/osis/model:dataset
corresponds to <selector xpath="model:data/*/model:author"/>
Discussion:
The * seems to confuse the checker, as model:author element does occurs,
for
instance model:data/model:names/model:name/model:authority/model:author
4) No corresponding element in base type, occuring at line 462, 467 and 472
Message:
No node in element http://lis.snv.jussieu.fr/~rousse/osis/model:dataset
corresponds to <selector
xpath="model:data/model:publications/model:publication/model:publisher"/>
Discussion:
The specified element does not exist for the base type, but for a derivated
type only, used with the same element and a xsi:type attribute
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://bohm.snv.jussieu.fr/~rousse/gpgkey.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
