You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by John Kaputin <KA...@uk.ibm.com> on 2006/01/21 03:55:19 UTC
Set referenceability of schemas during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable() and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by Arthur Ryman <ry...@ca.ibm.com>.
John,
I think the API should return the component model even if some component
assertions fail, although I regard this as a secondary priority. The focus
for the project now should be to help get the spec out of CR. So just
focus on implementing the spec faithfully and report back findings based
on implementation experience.
After CR, Woden should support advanced use cases. For example, one nice
feature in Eclipse is Quick Fixes. These are suggestions as to how to
repair invalid documents. The Eclipse WSDL 2.0 would need to work with the
invalid component model and apply some smarts to generate suggestions. The
editor should be able to update the element model and then rerun the
assertions. For efficiency, it would be desirable to programmatically
invoke the Document validator on an in-memory element model.
Content assist is another advanced use case. While editing an invalid
document it is desirable to have content assist based on the document at
least up to the point it becomes invalid. Content assist should be able to
base suggestions on the valid parts of the element or component model.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
John Kaputin <KA...@uk.ibm.com>
01/25/2006 05:30 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: Set referenceability of schemas during validation
Arthur,
the steps involved in readWSDL() are:
1. parse the WSDL into the Element model
2. run the Document validator against the Element model and report any
assertion errors
3. if no Document assertions fail, run the Component validator against the
Component model and report any assertion errors
4. return the DescriptionElement
After step 4. the user can call DescriptionElement.toComponent() to get
the
Description Component (i.e. even if errors were reported by steps 2 or 3).
So it's possible to have a Description Component with reported Document
assertion errors and unknown Component assertions (i.e. if Document
assertions fail at step 2, we don't validate the Component assertions at
step 3) or with no Document assertion errors but with reported Component
assertions errors. In both cases we just return the DescriptionElement
as-is ... and the user can then call toComponent() on it.
I don't think this behaviour is necessarily wrong. It depends on the use
cases that we want to support and we haven't clearly defined those yet.
For
the WSDL editor use case, it seems correct to return the Element model
(and
maybe the Component model) that represents the WSDL, even if it contains
errors.
regards,
John Kaputin
Arthur Ryman
<ryman@ca.ibm.com
> To
woden-dev@ws.apache.org
24/01/2006 22:45 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
Seems like Woden needs to be able to create an invalid component model
since the validation rules have to run against something. Isn't there
really a two-pass processing taking place? Pass 1 is to build up the data
structure but reading the documents. Pass 2 is to run the validation rules
and report errors. The thing created in Pass 1 is therefore not
necessarily
valid.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/24/2006 07:06 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
I agree that we should permit Woden to build an incomplete or invalid
Element model (i.e. if we are running with validation off or with
validation on & continue-on-error on). And I do think that all schemas,
valid and invalid, should be represented in the Element model. I guess my
fundamental question is whether Woden should be able to return an
incomplete or invalid Component model too (i.e. by calling toComponent()
on
an incomplete/invalid DescriptionElement). If the answer is 'yes' then my
question about schema referenceability goes away - all schemas should get
used to populate the {ElementDeclarations} and {TypeDefinitions}
properties
of the Description Component.
I created 3 test cases to check exactly how these errors are currently
handled in Woden and the results were not quite what I expected. See the
attached test cases:
Schema-0019.wsdl (has an inlined schema with no targetNamespace attribute)
Schema-0017.wsdl
Schema-0017.xsd (this imported schema has no targetNamespace attribute)
Schema-0052.wsdl
Schema-0052.xsd (this imported schema has a different targetNamespace)
(See attached file: Schema-0019.wsdl)(See attached file: Schema-0017.wsdl)
(See attached file: Schema-0017.xsd)(See attached file: Schema-0052.wsdl)
(See attached file: Schema-0052.xsd)
The Schema-0019 test was fine. As expected, it resulted in errors
Schema-0019 (inline schema has no TNS) and Schema-0016 (the fault
'element'
attribute references an unknown namespace).
The Schema-0017 test did not report Schema-0017 message as expected
because
although the testAssertionSchema0017 method tests the imported XmlSchema
for a targetNamespace of null or empty string, the
XmlSchema.getTargetNamespace method returns the string "DEFAULT". Either
the testAssertionSchema0017 method or the behaviour of XmlSchema needs to
be changed. This test case did however report Schema-0052 (imported
schema
has a different NS). I think the validator should just report Schema-0017,
but not Schema-0052 as well (i.e. Schema-0017 is more precise, making
Schema-0052 redundant).
I had expected the Schema-0017 test case to report Schema-0016 as well,
because the fault 'element' attribute was referencing a namespace that was
not in the imported schema. However, the testAssertionSchema0016 method
compares the namespace of the fault 'element' attribute to the 'namespace'
attribute of the xs:import (which is the same), not to the
'targetNamespace' attribute of the imported schema (which is different).
I'm not sure what the correct comparison should be in this case, but as
it's currently implemented the Schema-0016 assertion is succesful even
though there is no valid schema containing the element decalaration
referenced by the fault 'element' attribute.
The Schema-0052 test case did report the Schema-0052 error as expected,
but
it did not report the Schema-0016 error for the same reason described
above.
Hope this makes sense. More questions that answers...sorry :-(
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
24/01/2006 04:38 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
"Note that a WSDL 2.0 document must not import a schema that does not have
a targetNamespace"
I interpret this as a valid WSDL 2.0 document must not import a schema. As
we've discussed, I think Woden should be able to create an invalid model.
(The validator will flag the errors.) Editing a WSDL document using Woden
is a use case that has the invalid model requirement.
>From a validator perspective, if we don't import schemas where the
namespaces do not match, not only will the namespace assertions fail but
the assertions looking for defined elements will fail as well. This may be
confusing for users as the only fix required in the document is for the
namespace.
Arthur/Sanjiva - I'm also interested in a working group perspective on
this
case.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 07:22 PM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Arthur/Sanjiva,
I am interested in your WG views on this discussion. It's not clear to me
how to handle schemas that fail the schema assertions. I think the
following 3 choices apply, but maybe not uniformly across the different
types of assertions.
1. don't parse the schema (i.e. don't represent it in the model at all)
2. parse the schema into the Element model, report validation errors, but
don't represent its Elements and Types in the Component model.
3. parse the schema into the Element model, report validation errors and
do
represent its Elements and Types in the Component model.
The current behaviour in Woden is option 3 and this discussion thread
started because my thinking was based on option 2.
The key schema assertions are:
Schema-0016 A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information
item
for that namespace is present ...
Schema-0017 The referenced schema MUST contain a targetNamespace ...
(relates to imported schemas)
Schema-0019 The xs:schema element information item MUST contain a
targetNamespace ... (relates to inlined schemas)
Schema-0052 The value of the targetNamespace attribute information item of
the xs:schema element information item of an imported schema MUST equal
the
value of the namespace of the import ...
I agree with Lawrence that if an xs:import is missing its namespace
attribute, we don't attempt to retrieve the schema document. What about
the other assertions? Do you think these schemas should still be fully
represented in the Woden Element and Component models? Should we default
to the xs:import namespace for a Schema-0017 failure, or leave the
namespace empty?
I notice some text in Part 1 shortly after the Schema-0017 text that says:
Note that a WSDL 2.0 document must not import a schema that does not have
a
targetNamespace
Does this mean the Woden parser should discard such a schema rather than
parsing it? Or does it imply that we do parse it, but report the error?
thanks in advance for your advice,
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/01/2006 17:27 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 05:46 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations}
and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as
'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but
once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before
validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable()
and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or
testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description
component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org (See
attached
file: Schema-0019.wsdl)(See attached file: Schema-0017.wsdl)(See attached
file: Schema-0017.xsd)(See attached file: Schema-0052.wsdl)(See attached
file: Schema-0052.xsd)
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by John Kaputin <KA...@uk.ibm.com>.
Arthur,
the steps involved in readWSDL() are:
1. parse the WSDL into the Element model
2. run the Document validator against the Element model and report any
assertion errors
3. if no Document assertions fail, run the Component validator against the
Component model and report any assertion errors
4. return the DescriptionElement
After step 4. the user can call DescriptionElement.toComponent() to get the
Description Component (i.e. even if errors were reported by steps 2 or 3).
So it's possible to have a Description Component with reported Document
assertion errors and unknown Component assertions (i.e. if Document
assertions fail at step 2, we don't validate the Component assertions at
step 3) or with no Document assertion errors but with reported Component
assertions errors. In both cases we just return the DescriptionElement
as-is ... and the user can then call toComponent() on it.
I don't think this behaviour is necessarily wrong. It depends on the use
cases that we want to support and we haven't clearly defined those yet. For
the WSDL editor use case, it seems correct to return the Element model (and
maybe the Component model) that represents the WSDL, even if it contains
errors.
regards,
John Kaputin
Arthur Ryman
<ryman@ca.ibm.com
> To
woden-dev@ws.apache.org
24/01/2006 22:45 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
Seems like Woden needs to be able to create an invalid component model
since the validation rules have to run against something. Isn't there
really a two-pass processing taking place? Pass 1 is to build up the data
structure but reading the documents. Pass 2 is to run the validation rules
and report errors. The thing created in Pass 1 is therefore not necessarily
valid.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/24/2006 07:06 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
I agree that we should permit Woden to build an incomplete or invalid
Element model (i.e. if we are running with validation off or with
validation on & continue-on-error on). And I do think that all schemas,
valid and invalid, should be represented in the Element model. I guess my
fundamental question is whether Woden should be able to return an
incomplete or invalid Component model too (i.e. by calling toComponent() on
an incomplete/invalid DescriptionElement). If the answer is 'yes' then my
question about schema referenceability goes away - all schemas should get
used to populate the {ElementDeclarations} and {TypeDefinitions} properties
of the Description Component.
I created 3 test cases to check exactly how these errors are currently
handled in Woden and the results were not quite what I expected. See the
attached test cases:
Schema-0019.wsdl (has an inlined schema with no targetNamespace attribute)
Schema-0017.wsdl
Schema-0017.xsd (this imported schema has no targetNamespace attribute)
Schema-0052.wsdl
Schema-0052.xsd (this imported schema has a different targetNamespace)
(See attached file: Schema-0019.wsdl)(See attached file: Schema-0017.wsdl)
(See attached file: Schema-0017.xsd)(See attached file: Schema-0052.wsdl)
(See attached file: Schema-0052.xsd)
The Schema-0019 test was fine. As expected, it resulted in errors
Schema-0019 (inline schema has no TNS) and Schema-0016 (the fault 'element'
attribute references an unknown namespace).
The Schema-0017 test did not report Schema-0017 message as expected because
although the testAssertionSchema0017 method tests the imported XmlSchema
for a targetNamespace of null or empty string, the
XmlSchema.getTargetNamespace method returns the string "DEFAULT". Either
the testAssertionSchema0017 method or the behaviour of XmlSchema needs to
be changed. This test case did however report Schema-0052 (imported schema
has a different NS). I think the validator should just report Schema-0017,
but not Schema-0052 as well (i.e. Schema-0017 is more precise, making
Schema-0052 redundant).
I had expected the Schema-0017 test case to report Schema-0016 as well,
because the fault 'element' attribute was referencing a namespace that was
not in the imported schema. However, the testAssertionSchema0016 method
compares the namespace of the fault 'element' attribute to the 'namespace'
attribute of the xs:import (which is the same), not to the
'targetNamespace' attribute of the imported schema (which is different).
I'm not sure what the correct comparison should be in this case, but as
it's currently implemented the Schema-0016 assertion is succesful even
though there is no valid schema containing the element decalaration
referenced by the fault 'element' attribute.
The Schema-0052 test case did report the Schema-0052 error as expected, but
it did not report the Schema-0016 error for the same reason described
above.
Hope this makes sense. More questions that answers...sorry :-(
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
24/01/2006 04:38 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
"Note that a WSDL 2.0 document must not import a schema that does not have
a targetNamespace"
I interpret this as a valid WSDL 2.0 document must not import a schema. As
we've discussed, I think Woden should be able to create an invalid model.
(The validator will flag the errors.) Editing a WSDL document using Woden
is a use case that has the invalid model requirement.
>From a validator perspective, if we don't import schemas where the
namespaces do not match, not only will the namespace assertions fail but
the assertions looking for defined elements will fail as well. This may be
confusing for users as the only fix required in the document is for the
namespace.
Arthur/Sanjiva - I'm also interested in a working group perspective on this
case.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 07:22 PM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Arthur/Sanjiva,
I am interested in your WG views on this discussion. It's not clear to me
how to handle schemas that fail the schema assertions. I think the
following 3 choices apply, but maybe not uniformly across the different
types of assertions.
1. don't parse the schema (i.e. don't represent it in the model at all)
2. parse the schema into the Element model, report validation errors, but
don't represent its Elements and Types in the Component model.
3. parse the schema into the Element model, report validation errors and do
represent its Elements and Types in the Component model.
The current behaviour in Woden is option 3 and this discussion thread
started because my thinking was based on option 2.
The key schema assertions are:
Schema-0016 A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information item
for that namespace is present ...
Schema-0017 The referenced schema MUST contain a targetNamespace ...
(relates to imported schemas)
Schema-0019 The xs:schema element information item MUST contain a
targetNamespace ... (relates to inlined schemas)
Schema-0052 The value of the targetNamespace attribute information item of
the xs:schema element information item of an imported schema MUST equal the
value of the namespace of the import ...
I agree with Lawrence that if an xs:import is missing its namespace
attribute, we don't attempt to retrieve the schema document. What about
the other assertions? Do you think these schemas should still be fully
represented in the Woden Element and Component models? Should we default
to the xs:import namespace for a Schema-0017 failure, or leave the
namespace empty?
I notice some text in Part 1 shortly after the Schema-0017 text that says:
Note that a WSDL 2.0 document must not import a schema that does not have a
targetNamespace
Does this mean the Woden parser should discard such a schema rather than
parsing it? Or does it imply that we do parse it, but report the error?
thanks in advance for your advice,
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/01/2006 17:27 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 05:46 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations} and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as 'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable() and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org (See attached
file: Schema-0019.wsdl)(See attached file: Schema-0017.wsdl)(See attached
file: Schema-0017.xsd)(See attached file: Schema-0052.wsdl)(See attached
file: Schema-0052.xsd)
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by Arthur Ryman <ry...@ca.ibm.com>.
John,
Seems like Woden needs to be able to create an invalid component model
since the validation rules have to run against something. Isn't there
really a two-pass processing taking place? Pass 1 is to build up the data
structure but reading the documents. Pass 2 is to run the validation rules
and report errors. The thing created in Pass 1 is therefore not
necessarily valid.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
John Kaputin <KA...@uk.ibm.com>
01/24/2006 07:06 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: Set referenceability of schemas during validation
Lawrence,
I agree that we should permit Woden to build an incomplete or invalid
Element model (i.e. if we are running with validation off or with
validation on & continue-on-error on). And I do think that all schemas,
valid and invalid, should be represented in the Element model. I guess my
fundamental question is whether Woden should be able to return an
incomplete or invalid Component model too (i.e. by calling toComponent()
on
an incomplete/invalid DescriptionElement). If the answer is 'yes' then my
question about schema referenceability goes away - all schemas should get
used to populate the {ElementDeclarations} and {TypeDefinitions}
properties
of the Description Component.
I created 3 test cases to check exactly how these errors are currently
handled in Woden and the results were not quite what I expected. See the
attached test cases:
Schema-0019.wsdl (has an inlined schema with no targetNamespace attribute)
Schema-0017.wsdl
Schema-0017.xsd (this imported schema has no targetNamespace attribute)
Schema-0052.wsdl
Schema-0052.xsd (this imported schema has a different targetNamespace)
(See attached file: Schema-0019.wsdl)(See attached file: Schema-0017.wsdl)
(See attached file: Schema-0017.xsd)(See attached file: Schema-0052.wsdl)
(See attached file: Schema-0052.xsd)
The Schema-0019 test was fine. As expected, it resulted in errors
Schema-0019 (inline schema has no TNS) and Schema-0016 (the fault
'element'
attribute references an unknown namespace).
The Schema-0017 test did not report Schema-0017 message as expected
because
although the testAssertionSchema0017 method tests the imported XmlSchema
for a targetNamespace of null or empty string, the
XmlSchema.getTargetNamespace method returns the string "DEFAULT". Either
the testAssertionSchema0017 method or the behaviour of XmlSchema needs to
be changed. This test case did however report Schema-0052 (imported
schema
has a different NS). I think the validator should just report Schema-0017,
but not Schema-0052 as well (i.e. Schema-0017 is more precise, making
Schema-0052 redundant).
I had expected the Schema-0017 test case to report Schema-0016 as well,
because the fault 'element' attribute was referencing a namespace that was
not in the imported schema. However, the testAssertionSchema0016 method
compares the namespace of the fault 'element' attribute to the 'namespace'
attribute of the xs:import (which is the same), not to the
'targetNamespace' attribute of the imported schema (which is different).
I'm not sure what the correct comparison should be in this case, but as
it's currently implemented the Schema-0016 assertion is succesful even
though there is no valid schema containing the element decalaration
referenced by the fault 'element' attribute.
The Schema-0052 test case did report the Schema-0052 error as expected,
but
it did not report the Schema-0016 error for the same reason described
above.
Hope this makes sense. More questions that answers...sorry :-(
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
24/01/2006 04:38 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
"Note that a WSDL 2.0 document must not import a schema that does not have
a targetNamespace"
I interpret this as a valid WSDL 2.0 document must not import a schema. As
we've discussed, I think Woden should be able to create an invalid model.
(The validator will flag the errors.) Editing a WSDL document using Woden
is a use case that has the invalid model requirement.
>From a validator perspective, if we don't import schemas where the
namespaces do not match, not only will the namespace assertions fail but
the assertions looking for defined elements will fail as well. This may be
confusing for users as the only fix required in the document is for the
namespace.
Arthur/Sanjiva - I'm also interested in a working group perspective on
this
case.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 07:22 PM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Arthur/Sanjiva,
I am interested in your WG views on this discussion. It's not clear to me
how to handle schemas that fail the schema assertions. I think the
following 3 choices apply, but maybe not uniformly across the different
types of assertions.
1. don't parse the schema (i.e. don't represent it in the model at all)
2. parse the schema into the Element model, report validation errors, but
don't represent its Elements and Types in the Component model.
3. parse the schema into the Element model, report validation errors and
do
represent its Elements and Types in the Component model.
The current behaviour in Woden is option 3 and this discussion thread
started because my thinking was based on option 2.
The key schema assertions are:
Schema-0016 A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information
item
for that namespace is present ...
Schema-0017 The referenced schema MUST contain a targetNamespace ...
(relates to imported schemas)
Schema-0019 The xs:schema element information item MUST contain a
targetNamespace ... (relates to inlined schemas)
Schema-0052 The value of the targetNamespace attribute information item of
the xs:schema element information item of an imported schema MUST equal
the
value of the namespace of the import ...
I agree with Lawrence that if an xs:import is missing its namespace
attribute, we don't attempt to retrieve the schema document. What about
the other assertions? Do you think these schemas should still be fully
represented in the Woden Element and Component models? Should we default
to the xs:import namespace for a Schema-0017 failure, or leave the
namespace empty?
I notice some text in Part 1 shortly after the Schema-0017 text that says:
Note that a WSDL 2.0 document must not import a schema that does not have
a
targetNamespace
Does this mean the Woden parser should discard such a schema rather than
parsing it? Or does it imply that we do parse it, but report the error?
thanks in advance for your advice,
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/01/2006 17:27 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 05:46 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations}
and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as
'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but
once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before
validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable()
and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or
testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description
component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by John Kaputin <KA...@uk.ibm.com>.
Lawrence,
I agree that we should permit Woden to build an incomplete or invalid
Element model (i.e. if we are running with validation off or with
validation on & continue-on-error on). And I do think that all schemas,
valid and invalid, should be represented in the Element model. I guess my
fundamental question is whether Woden should be able to return an
incomplete or invalid Component model too (i.e. by calling toComponent() on
an incomplete/invalid DescriptionElement). If the answer is 'yes' then my
question about schema referenceability goes away - all schemas should get
used to populate the {ElementDeclarations} and {TypeDefinitions} properties
of the Description Component.
I created 3 test cases to check exactly how these errors are currently
handled in Woden and the results were not quite what I expected. See the
attached test cases:
Schema-0019.wsdl (has an inlined schema with no targetNamespace attribute)
Schema-0017.wsdl
Schema-0017.xsd (this imported schema has no targetNamespace attribute)
Schema-0052.wsdl
Schema-0052.xsd (this imported schema has a different targetNamespace)
(See attached file: Schema-0019.wsdl)(See attached file: Schema-0017.wsdl)
(See attached file: Schema-0017.xsd)(See attached file: Schema-0052.wsdl)
(See attached file: Schema-0052.xsd)
The Schema-0019 test was fine. As expected, it resulted in errors
Schema-0019 (inline schema has no TNS) and Schema-0016 (the fault 'element'
attribute references an unknown namespace).
The Schema-0017 test did not report Schema-0017 message as expected because
although the testAssertionSchema0017 method tests the imported XmlSchema
for a targetNamespace of null or empty string, the
XmlSchema.getTargetNamespace method returns the string "DEFAULT". Either
the testAssertionSchema0017 method or the behaviour of XmlSchema needs to
be changed. This test case did however report Schema-0052 (imported schema
has a different NS). I think the validator should just report Schema-0017,
but not Schema-0052 as well (i.e. Schema-0017 is more precise, making
Schema-0052 redundant).
I had expected the Schema-0017 test case to report Schema-0016 as well,
because the fault 'element' attribute was referencing a namespace that was
not in the imported schema. However, the testAssertionSchema0016 method
compares the namespace of the fault 'element' attribute to the 'namespace'
attribute of the xs:import (which is the same), not to the
'targetNamespace' attribute of the imported schema (which is different).
I'm not sure what the correct comparison should be in this case, but as
it's currently implemented the Schema-0016 assertion is succesful even
though there is no valid schema containing the element decalaration
referenced by the fault 'element' attribute.
The Schema-0052 test case did report the Schema-0052 error as expected, but
it did not report the Schema-0016 error for the same reason described
above.
Hope this makes sense. More questions that answers...sorry :-(
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
24/01/2006 04:38 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
"Note that a WSDL 2.0 document must not import a schema that does not have
a targetNamespace"
I interpret this as a valid WSDL 2.0 document must not import a schema. As
we've discussed, I think Woden should be able to create an invalid model.
(The validator will flag the errors.) Editing a WSDL document using Woden
is a use case that has the invalid model requirement.
>From a validator perspective, if we don't import schemas where the
namespaces do not match, not only will the namespace assertions fail but
the assertions looking for defined elements will fail as well. This may be
confusing for users as the only fix required in the document is for the
namespace.
Arthur/Sanjiva - I'm also interested in a working group perspective on this
case.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 07:22 PM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Arthur/Sanjiva,
I am interested in your WG views on this discussion. It's not clear to me
how to handle schemas that fail the schema assertions. I think the
following 3 choices apply, but maybe not uniformly across the different
types of assertions.
1. don't parse the schema (i.e. don't represent it in the model at all)
2. parse the schema into the Element model, report validation errors, but
don't represent its Elements and Types in the Component model.
3. parse the schema into the Element model, report validation errors and do
represent its Elements and Types in the Component model.
The current behaviour in Woden is option 3 and this discussion thread
started because my thinking was based on option 2.
The key schema assertions are:
Schema-0016 A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information item
for that namespace is present ...
Schema-0017 The referenced schema MUST contain a targetNamespace ...
(relates to imported schemas)
Schema-0019 The xs:schema element information item MUST contain a
targetNamespace ... (relates to inlined schemas)
Schema-0052 The value of the targetNamespace attribute information item of
the xs:schema element information item of an imported schema MUST equal the
value of the namespace of the import ...
I agree with Lawrence that if an xs:import is missing its namespace
attribute, we don't attempt to retrieve the schema document. What about
the other assertions? Do you think these schemas should still be fully
represented in the Woden Element and Component models? Should we default
to the xs:import namespace for a Schema-0017 failure, or leave the
namespace empty?
I notice some text in Part 1 shortly after the Schema-0017 text that says:
Note that a WSDL 2.0 document must not import a schema that does not have a
targetNamespace
Does this mean the Woden parser should discard such a schema rather than
parsing it? Or does it imply that we do parse it, but report the error?
thanks in advance for your advice,
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/01/2006 17:27 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 05:46 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations} and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as 'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable() and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
John,
"Note that a WSDL 2.0 document must not import a schema that does not have
a targetNamespace"
I interpret this as a valid WSDL 2.0 document must not import a schema. As
we've discussed, I think Woden should be able to create an invalid model.
(The validator will flag the errors.) Editing a WSDL document using Woden
is a use case that has the invalid model requirement.
>From a validator perspective, if we don't import schemas where the
namespaces do not match, not only will the namespace assertions fail but
the assertions looking for defined elements will fail as well. This may be
confusing for users as the only fix required in the document is for the
namespace.
Arthur/Sanjiva - I'm also interested in a working group perspective on
this case.
Lawrence Mandel
John Kaputin <KA...@uk.ibm.com>
01/23/2006 07:22 PM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: Set referenceability of schemas during validation
Arthur/Sanjiva,
I am interested in your WG views on this discussion. It's not clear to me
how to handle schemas that fail the schema assertions. I think the
following 3 choices apply, but maybe not uniformly across the different
types of assertions.
1. don't parse the schema (i.e. don't represent it in the model at all)
2. parse the schema into the Element model, report validation errors, but
don't represent its Elements and Types in the Component model.
3. parse the schema into the Element model, report validation errors and
do
represent its Elements and Types in the Component model.
The current behaviour in Woden is option 3 and this discussion thread
started because my thinking was based on option 2.
The key schema assertions are:
Schema-0016 A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information
item
for that namespace is present ...
Schema-0017 The referenced schema MUST contain a targetNamespace ...
(relates to imported schemas)
Schema-0019 The xs:schema element information item MUST contain a
targetNamespace ... (relates to inlined schemas)
Schema-0052 The value of the targetNamespace attribute information item of
the xs:schema element information item of an imported schema MUST equal
the
value of the namespace of the import ...
I agree with Lawrence that if an xs:import is missing its namespace
attribute, we don't attempt to retrieve the schema document. What about
the other assertions? Do you think these schemas should still be fully
represented in the Woden Element and Component models? Should we default
to the xs:import namespace for a Schema-0017 failure, or leave the
namespace empty?
I notice some text in Part 1 shortly after the Schema-0017 text that says:
Note that a WSDL 2.0 document must not import a schema that does not have
a
targetNamespace
Does this mean the Woden parser should discard such a schema rather than
parsing it? Or does it imply that we do parse it, but report the error?
thanks in advance for your advice,
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/01/2006 17:27 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 05:46 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations}
and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as
'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but
once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before
validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable()
and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or
testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description
component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by John Kaputin <KA...@uk.ibm.com>.
Arthur/Sanjiva,
I am interested in your WG views on this discussion. It's not clear to me
how to handle schemas that fail the schema assertions. I think the
following 3 choices apply, but maybe not uniformly across the different
types of assertions.
1. don't parse the schema (i.e. don't represent it in the model at all)
2. parse the schema into the Element model, report validation errors, but
don't represent its Elements and Types in the Component model.
3. parse the schema into the Element model, report validation errors and do
represent its Elements and Types in the Component model.
The current behaviour in Woden is option 3 and this discussion thread
started because my thinking was based on option 2.
The key schema assertions are:
Schema-0016 A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information item
for that namespace is present ...
Schema-0017 The referenced schema MUST contain a targetNamespace ...
(relates to imported schemas)
Schema-0019 The xs:schema element information item MUST contain a
targetNamespace ... (relates to inlined schemas)
Schema-0052 The value of the targetNamespace attribute information item of
the xs:schema element information item of an imported schema MUST equal the
value of the namespace of the import ...
I agree with Lawrence that if an xs:import is missing its namespace
attribute, we don't attempt to retrieve the schema document. What about
the other assertions? Do you think these schemas should still be fully
represented in the Woden Element and Component models? Should we default
to the xs:import namespace for a Schema-0017 failure, or leave the
namespace empty?
I notice some text in Part 1 shortly after the Schema-0017 text that says:
Note that a WSDL 2.0 document must not import a schema that does not have a
targetNamespace
Does this mean the Woden parser should discard such a schema rather than
parsing it? Or does it imply that we do parse it, but report the error?
thanks in advance for your advice,
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/01/2006 17:27 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/23/2006 05:46 AM cc
Subject
Please respond to Re: Set referenceability of
woden-dev schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations} and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as 'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable() and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
John,
>However, I still need to ensure that any schemas that are invalid (e.g.
>because of import namespace or target namespace errors) are flagged
>accordingly so that they do not contribute to the {ElementDeclarations}
and
>{TypeDefinitions} properties of the Description component. That is, such
>schemas will exist in the Element model because they exist in the WSDL
>documents, but they should not form part of the Component model.
In these cases I think the component model should contain the elements and
types from the imported schemas even though the namespace information may
be incorrect. The parser can still import the schemas and the validator
will only flag the namespace related problems instead of also reporting
that the types are invalid. I suggest that the elements and types be added
to the component model using the namespace specified in the WSDL import
statement. If no namespace is specified on an import statement or on an
inline schema it is an error so do not bother parsing the schema at all.
(No need to report an error in these cases as the validator will already
handle this.)
I don't think we should duplicate validation logic from the validator to
the parser. This will undoubtedly lead to maintenance trouble and may
result in duplicate errors being reported.
Lawrence Mandel
John Kaputin <KA...@uk.ibm.com>
01/23/2006 05:46 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: Set referenceability of schemas during validation
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations}
and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as
'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but
once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before
validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable()
and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or
testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description
component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by John Kaputin <KA...@uk.ibm.com>.
Lawrence,
the separation you describe sounds reasonable, so let's reject my initial
suggestion.
However, I still need to ensure that any schemas that are invalid (e.g.
because of import namespace or target namespace errors) are flagged
accordingly so that they do not contribute to the {ElementDeclarations} and
{TypeDefinitions} properties of the Description component. That is, such
schemas will exist in the Element model because they exist in the WSDL
documents, but they should not form part of the Component model.
To achieve this I will add to the parser logic equivalent checks to those
performed for the assertions Schema-0017, Schema-0019 and Schema-0052. If
any schema fails these assertions at parse-time, it will be flagged as 'not
referenceable'. The ComponentModelBuilder can later make use of this
information.
The cost of doing these checks twice is insignificant. We will need to
ensure that the parser and validator stay in sync on these checks, but once
the WSDL spec is finalized these assertions are unlikely to change, so a
suitable comment in the parser should be sufficient to document this.
John Kaputin
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
22/01/2006 20:16 cc
Subject
Please respond to Re: Set referenceability of schemas
woden-dev during validation
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before validation
is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
01/20/2006 09:55 PM cc
Subject
Please respond to Set referenceability of schemas
woden-dev during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable() and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Set referenceability of schemas during validation
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
John,
I don't like the idea of tying model functionality to the validator. The
validator should be independent from the model and run after the model is
created. The model, in turn, should be completely created before
validation is run or even if validation is not run.
I think keeping the model and validator separate is important for other
Woden API adopters who wish to create their own implementation. Any
implementation of the Woden WSDL 2.0 API should be able to make use of the
validator as is.
Comments?
Lawrence Mandel
John Kaputin <KA...@uk.ibm.com>
01/20/2006 09:55 PM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Set referenceability of schemas during validation
Lawrence,
I created SchemaImpl with two public non-API methods, isReferenceable()
and
setReferenceable(boolean), with the idea that validation would set this
property to 'false' if the schema assertions failed. Then, when the
descElement.toComponent() method runs the ComponentBuilder, it could
initialize the {Element Declaration} and {Type Definition} properties from
'referenceable' schemas only. To assist with this, TypesImpl has the
public non-API helper method getReferenceableSchemas().
Examples of schemas that are not referenceable in the WSDL are:
- schemas without a target namespace (Schema-0017, Schema-0019)
- schemas resolved from a xs:import whose target namespace does not match
the import namespace (Schema-0052).
I'd like some code added to the WSDLDocumentValidator.validateTypes method
to call SchemaImpl.setReferenceable(false) if false is returned by
testAssertionSchema0017, testAssertionSchema0019 or
testAssertionSchema0052
methods.
Then later when testAssertionsSchema0020 and testAssertionsSchema0020b get
called, and they in turn call desc.toComponent(), the Description
component
will be initialized as described above, from referenceable schemas only.
How does this sound?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org