XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
David AndrzejekSubject: two error messages
Author: David Andrzejek
Date: 21 Feb 2003 12:20 PM
Hi.
I am having a problem figuring out why Stylus Studio is giving me two error messages.

Attached are screen prints of the problems, and a zip file containing a relatively simple example duplicating each.
Any help is appreciated. Thanks!


Applicationproblemsamples.zip
samples

Imageerrors.ZIP
error1

Postnext
Alberto MassariSubject: Re: two error messages
Author: Alberto Massari
Date: 21 Feb 2003 12:56 PM
At 12.39 21/02/2003 -0500, you wrote:
>From: "David Andrzejek"
>
>Hi.
>I am having a problem figuring out why Stylus Studio is giving me two
>error messages.
>[...]

In the first case (Level2Restriction.xsd), you have a base class
(Insurance:PolicyClass) defined as a sequence of two elements,
Insurance:CreditSurcharges and Insurance:PropertySchedule. Then you derive
from this a Level2:MyPolicyClass, but, instead of redefining the
cardinality of the components of the parent class, you are effectively
trying to replace them with Level2:CreditSurcharges and
Level2:PropertySchedule (because you are now working inside the Level2
namespace).
A correct schema would be





ref="Insurance:CreditSurcharges"/>
ref="Insurance:PropertySchedule" minOccurs="0" maxOccurs="10"/>





The same applies to the second testcase; you are trying to replace the
definition for Insurance:CreditSurcharge (derived from
Base:PolicyCreditSurchargeClass) with a brand new MyModel:CreditSurcharges
derived from Insurance:CreditSurcharge.

Alberto

Postnext
Ken GrossSubject: Re: two error messages
Author: Ken Gross
Date: 21 Feb 2003 11:29 PM
I don't agree with this analysis because Level1 and Level2 are the same construct. But Stylus Studio reports a problem with Level2 but not Level1. Either they are both invalid or both valid.

Postnext
Ivan PedruzziSubject: RE: two error messages
Author: Ivan Pedruzzi
Date: 22 Feb 2003 01:14 AM

In the Level1 'PolicyClass' content can be anything because you are
restricting an anyType element in the ##any namespace.
You are allow to do it.

In the Level2 'MyModel:MyPolicyClass' try to restrict a well defined
Base:PolicyClass; because you are using anonymous declarations the
element 'CreditSurcharges' is part of the target namespace, then the
definiton clashes with his ancestor.


Ivan

> -----Original Message-----
> From: stylus-studio-tech Listmanager
> [mailto:listmanager@edn.exln.com]
> Sent: Friday, February 21, 2003 11:48 PM
> To: Recipients of 'stylus-studio-tech' suppressed
> Subject: Re: two error messages
>
>
> From: "Ken Gross"
>
> I don't agree with this analysis because Level1 and Level2
> are the same construct. But Stylus Studio reports a problem
> with Level2 but not Level1. Either they are both invalid or
> both valid.
>
>
>
>
> To reply: mailto:stylus-studio-tech.6319@edn.exln.com
> To start a new topic: mailto:stylus-studio-tech@edn.exln.com
> To login: http://edn.exln.com/~SSDN
>

Postnext
Ken GrossSubject: RE: two error messages
Author: Ken Gross
Date: 23 Feb 2003 12:16 PM
Ivan,

Thanks for your explaination. I appreciate the additional information. However, I still am not convinced.

A restriction of an object is still a version of the object, and should be treated as such.

Can you point me to a specific paragraph in the W3C standard which specifies that I cannot re-restrict an element in the spirit you are suggesting?

Thanks.

Postnext
Ivan PedruzziSubject: RE: two error messages
Author: Ivan Pedruzzi
Date: 23 Feb 2003 04:07 PM
Ken

I can read from
http://www.w3.org/TR/xmlschema-0/#DerivByRestrict

" A complex type derived by restriction is very similar to its base type, except that its declarations are more limited than the corresponding declarations in the base type. In fact, the values represented by the new type are a subset of the values represented by the base type (as is the case with restriction of simple types). In other words, an application prepared for the values of the base type would not be surprised by the values of the restricted type."

Given the above if your application was designed to receive a Base:PolicyClass and you feed it with a Insurance:PolicyClass it could fail. Even if the document structure is identical, the name space will not match

Postnext
Ken GrossSubject: RE: two error messages
Author: Ken Gross
Date: 24 Feb 2003 11:24 AM
In this case only the namespace has changed. Nothing else has changed at all. Is that sufficient reason to fail it?

Postnext
Alberto MassariSubject: RE: two error messages
Author: Alberto Massari
Date: 24 Feb 2003 11:36 AM
At 11.43 24/02/2003 -0500, you wrote:
>From: "Ken Gross"
>
>In this case only the namespace has changed. Nothing else has changed at=
>all. Is that sufficient reason to fail it?

Yes.
From the XMLSchema specs, § 3.9.6
(http://www.w3.org/TR/xmlschema-1/#cParticles)
"...
Schema Component Constraint: Particle Restriction OK (Elt:Elt --
NameAndTypeOK)
For an element declaration particle to be a ·valid restriction· of= another
element declaration particle all of the following must be true:
1 The declarations' {name}s and {target namespace}s are the same.
...."

All XML elements are uniquely identified by the pair uri/name; assuming
that two elements with the same name but different namespace are the same
thing is like assuming that "apple" means the same thing both in the
namespace "vegetables" and "software_companies".

Alberto

Postnext
Ken GrossSubject: RE: two error messages
Author: Ken Gross
Date: 24 Feb 2003 02:46 PM
Alberto,

Thanks for your answer. I think I understand the problem with new namespace.

However, it is not completely clear to me that the namespaces of the two redefined objects is "insurance". If you will notice, in Level 2 in the first example, the base is still in the "base" namespace even though the restrictions could possibly become more stringent. These elements are local within the global type which contains them.

So it is not clear to me that the namespace has changed since the elements are not global. What am I missing?

Ken

Posttop
Alberto MassariSubject: RE: two error messages
Author: Alberto Massari
Date: 25 Feb 2003 04:56 AM
At 15.05 24/02/2003 -0500, you wrote:
>From: "Ken Gross"
>
>Alberto,
>
>Thanks for your answer. I think I understand the problem with new namespace.
>
>However, it is not completely clear to me that the namespaces of the two
>redefined objects is "insurance". If you will notice, in Level 2 in the
>first example, the base is still in the "base" namespace even though the
>restrictions could possibly become more stringent. These elements are
>local within the global type which contains them.
>
>So it is not clear to me that the namespace has changed since the elements
>are not global. What am I missing?

The problem is not with the "base" namespace, so let's keep it out of the
picture.
In the Level1Restriction.xsd file, you have:

{w3cSchema:schema targetNamespace="Insurance" ...}
{w3cSchema:complexType name="PolicyClass"}
...
{w3cSchema:restriction base="Base:PolicyClass"}
...
{w3cSchema:element name="CreditSurcharges"}
...
{w3cSchema:element name="PropertySchedule"}
...

This creates a Insurance:PolicyClass, defined as the restriction from
Base:PolicyClass, with two locally defined elements names
Insurance:CreditSurcharges and Insurance:PropertySchedule (being defined in
this schema, they automatically fall into the Insurance namespace).

Then, in Level2Restriction.xsd, you have:

{w3cSchema:schema targetNamespace="Level2" ...}
{w3cSchema:complexType name="MyPolicyClass"}
...
{w3cSchema:restriction base="Insurance:PolicyClass"}
...
{w3cSchema:element name="CreditSurcharges"}
...
{w3cSchema:element name="PropertySchedule"}
...

This defines a new type Level2:MyPolicyClass, that derives by restriction
from Insurance:PolicyClass, and having two brand new elements as children,
Level2:CreditSurcharges and Level2:PropertySchedule.
So you are creating new types that by chance are exact copies of the
already existing Insurance:CreditSurcharges and Insurance:PropertySchedule,
and this is not allowed by the rules on restriction. What you could do is
to restrict their cardinality, by using

{w3cSchema:element ref="Insurance:CreditSurcharges" minOccurs=".."
maxOccurs=".."/}
{w3cSchema:element ref="Insurance:PropertySchedule" minOccurs=".."
maxOccurs=".."/}

("ref" reuses existing definitions, "name" create new ones in the
targetNamespace of the current file).

Alberto

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.