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 2005/10/12 11:54:17 UTC
Plan to handle parsing errors and validation.
Yesterday I discussed the qname issue and other validation issues with
Lawrence. This is a summary of how we plan to progress for milestone 2.
Any comments or suggestions are welcome.
Don't store the string values of attributes with prefixed names (as
proposed in John Kaputin's earlier posting). Resolve the namespaces and
create QNames at parse-time, reporting any namespace resolution errors as
they occur. If a namespace error does occur, create the QName with a ""
(empty string) namespace and whatever the local part and prefix are in the
xml. An empty string namespace will indicate to the Woden validator that a
namespace error exists for that QName. Note that unqualified names in the
WSDL will have the default namespace so the QName created will have a
namespace value equal to the default namespace, a local part equal to the
unqualified name and a prefix of "" (i.e. it won't use "" in the namespace
field, so we can use the "" convention described here for indicating QName
namespace errors).
WSDL validation in Woden includes schema validation (if supported by the
xml parser) and checking of the WSDL object model by the Woden validator.
Terminating errors in Woden include configuration errors and parser
exceptions such as DOMException. These will be wrapped, if necessary, and
thrown as WSDLExceptions and any in-progress parsing will stop.
Non-terminating errors are parse-time WSDL errors from which we can
continue, even if we can't build the complete wsdl model.
Unless terminating errors are encountered when parsing the WSDL, we should
try to create as much of the wsdl model as we can, even if we end up with a
partially complete wsdl model. If wsdl validation is turned on in Woden,
report the parse-time errors and carry on completing as much of the model
as possible. If validation is turned off, carry on creating the model if
possible without reporting the errors. One usage scenario for creating a
partially complete wsdl model with parse-time validation turned off is when
a WSDL editing tool is being used to work on an incomplete WSDL document
and the WSDL only gets validated when requested by the user.
TODO - consider the scenario where a runtime system may run with validation
turned off for performance - here, a parse-time error should probably
terminate with a WSDLException, not return a partially complete model.
Consider how to distinguish this scenario from the WSDL editor scenario
above (perhaps via reader configuration features)
For now, report any non-terminating, parse-time errors as they occur (e.g.
qname namespace resolution errors, xml parser warnings and non-fatal
errors). Later we can decide if these error messages should be cached at
parse-time and handled by the validator instead.
We will need a mechanism to determine at the end of the parse if any errors
have been reported either by Woden or by the xml parser so as not to
continue on with validating the Component model (i.e. report and fix the
known errors in the xml first).
In the xml-based wsdl model represented by the org.apache.woden.wsdl20.xml
interfaces (i.e. the xxxElement interfaces), we should base element
references on real xxxElement objects, not QNames or prefixed name strings.
For example, BindingElement should represent the <binding> element's
'interface' attribute with a reference to an InterfaceElement object (not
to its QName object).
We need to capture at parse-time the line/column numbers for the start tag
of each wsdl element. These are used by the ErrorReporter. We also plan to
use them for calculating offsets to pinpoint errors at a more fine-grained
level (e.g. error reporting that highlights particular attributes or
attribute values).
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: Plan to handle parsing errors and validation.
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
Reminds me of the 169.x.x.x address assigned when an IP address cannot be
obtained from a DHCP server. As John said, we should discuss this more.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
John Kaputin <KA...@uk.ibm.com>
10/13/2005 05:33 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: Plan to handle parsing errors and validation.
The empty string namespace in QName was just a way for the Reader to
capture the namespace error internally at parse-time, so the validator can
recognize it and decide how to handle it. A suitable error message would
always be reported as well.
We could certainly make the parse-time error more explicit to the
validator
by using a namespace string that reflects the error. Especially if there
are different types of parse-time QName namespace errors we need to
distinguish or if we decide we want the validator to report the error
message rather than report it at parse-time in the Reader as we do
currently.
Not sure if we want to externalize such a namespace string in QName to the
user application though. My thinking was that a suitable error message and
the wsdl model with the offending QName containing the original prefix and
an empty string namespace would be sufficient for the user. That is, the
error message makes the problem explicit to the user and the empty string
namespace indicates that we don't have any value for this property yet.
However, your suggestion to externalize the namespace error string in the
QName may be useful in a scenario where the calling application needs to
handle this error programatically (i.e. a runtime application where there
is no human user reading the error message).
Will give it some thought and confer with the Woden team.
thanks,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
12/10/2005 15:37 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Re: Plan to handle parsing errors
and validation.
> they occur. If a namespace error does occur, create the QName with a ""
> (empty string) namespace and whatever the local part and prefix are in
the
> xml. An empty string namespace will indicate to the Woden validator that
a
> namespace error exists for that QName. Note that unqualified names in
the
What about making the namespace error more explicit in the QName?
For example, using something like
"http://www.woden.org/unresolved-namespace-error/" instead of using "".
This way, users of the model might be able to make a better guess when the
error happens without learning the empty string namespace.
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
10/12/2005 05:54 cc
AM
Subject
Plan to handle parsing errors and
Please respond to validation.
woden-dev
Yesterday I discussed the qname issue and other validation issues with
Lawrence. This is a summary of how we plan to progress for milestone 2.
Any comments or suggestions are welcome.
Don't store the string values of attributes with prefixed names (as
proposed in John Kaputin's earlier posting). Resolve the namespaces and
create QNames at parse-time, reporting any namespace resolution errors as
they occur. If a namespace error does occur, create the QName with a ""
(empty string) namespace and whatever the local part and prefix are in the
xml. An empty string namespace will indicate to the Woden validator that a
namespace error exists for that QName. Note that unqualified names in the
WSDL will have the default namespace so the QName created will have a
namespace value equal to the default namespace, a local part equal to the
unqualified name and a prefix of "" (i.e. it won't use "" in the namespace
field, so we can use the "" convention described here for indicating QName
namespace errors).
WSDL validation in Woden includes schema validation (if supported by the
xml parser) and checking of the WSDL object model by the Woden validator.
Terminating errors in Woden include configuration errors and parser
exceptions such as DOMException. These will be wrapped, if necessary, and
thrown as WSDLExceptions and any in-progress parsing will stop.
Non-terminating errors are parse-time WSDL errors from which we can
continue, even if we can't build the complete wsdl model.
Unless terminating errors are encountered when parsing the WSDL, we should
try to create as much of the wsdl model as we can, even if we end up with
a
partially complete wsdl model. If wsdl validation is turned on in Woden,
report the parse-time errors and carry on completing as much of the model
as possible. If validation is turned off, carry on creating the model if
possible without reporting the errors. One usage scenario for creating a
partially complete wsdl model with parse-time validation turned off is
when
a WSDL editing tool is being used to work on an incomplete WSDL document
and the WSDL only gets validated when requested by the user.
TODO - consider the scenario where a runtime system may run with
validation
turned off for performance - here, a parse-time error should probably
terminate with a WSDLException, not return a partially complete model.
Consider how to distinguish this scenario from the WSDL editor scenario
above (perhaps via reader configuration features)
For now, report any non-terminating, parse-time errors as they occur (e.g.
qname namespace resolution errors, xml parser warnings and non-fatal
errors). Later we can decide if these error messages should be cached at
parse-time and handled by the validator instead.
We will need a mechanism to determine at the end of the parse if any
errors
have been reported either by Woden or by the xml parser so as not to
continue on with validating the Component model (i.e. report and fix the
known errors in the xml first).
In the xml-based wsdl model represented by the org.apache.woden.wsdl20.xml
interfaces (i.e. the xxxElement interfaces), we should base element
references on real xxxElement objects, not QNames or prefixed name
strings.
For example, BindingElement should represent the <binding> element's
'interface' attribute with a reference to an InterfaceElement object (not
to its QName object).
We need to capture at parse-time the line/column numbers for the start tag
of each wsdl element. These are used by the ErrorReporter. We also plan to
use them for calculating offsets to pinpoint errors at a more fine-grained
level (e.g. error reporting that highlights particular attributes or
attribute values).
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: Plan to handle parsing errors and validation.
Posted by John Kaputin <KA...@uk.ibm.com>.
The empty string namespace in QName was just a way for the Reader to
capture the namespace error internally at parse-time, so the validator can
recognize it and decide how to handle it. A suitable error message would
always be reported as well.
We could certainly make the parse-time error more explicit to the validator
by using a namespace string that reflects the error. Especially if there
are different types of parse-time QName namespace errors we need to
distinguish or if we decide we want the validator to report the error
message rather than report it at parse-time in the Reader as we do
currently.
Not sure if we want to externalize such a namespace string in QName to the
user application though. My thinking was that a suitable error message and
the wsdl model with the offending QName containing the original prefix and
an empty string namespace would be sufficient for the user. That is, the
error message makes the problem explicit to the user and the empty string
namespace indicates that we don't have any value for this property yet.
However, your suggestion to externalize the namespace error string in the
QName may be useful in a scenario where the calling application needs to
handle this error programatically (i.e. a runtime application where there
is no human user reading the error message).
Will give it some thought and confer with the Woden team.
thanks,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
12/10/2005 15:37 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Re: Plan to handle parsing errors
and validation.
> they occur. If a namespace error does occur, create the QName with a ""
> (empty string) namespace and whatever the local part and prefix are in
the
> xml. An empty string namespace will indicate to the Woden validator that
a
> namespace error exists for that QName. Note that unqualified names in the
What about making the namespace error more explicit in the QName?
For example, using something like
"http://www.woden.org/unresolved-namespace-error/" instead of using "".
This way, users of the model might be able to make a better guess when the
error happens without learning the empty string namespace.
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
10/12/2005 05:54 cc
AM
Subject
Plan to handle parsing errors and
Please respond to validation.
woden-dev
Yesterday I discussed the qname issue and other validation issues with
Lawrence. This is a summary of how we plan to progress for milestone 2.
Any comments or suggestions are welcome.
Don't store the string values of attributes with prefixed names (as
proposed in John Kaputin's earlier posting). Resolve the namespaces and
create QNames at parse-time, reporting any namespace resolution errors as
they occur. If a namespace error does occur, create the QName with a ""
(empty string) namespace and whatever the local part and prefix are in the
xml. An empty string namespace will indicate to the Woden validator that a
namespace error exists for that QName. Note that unqualified names in the
WSDL will have the default namespace so the QName created will have a
namespace value equal to the default namespace, a local part equal to the
unqualified name and a prefix of "" (i.e. it won't use "" in the namespace
field, so we can use the "" convention described here for indicating QName
namespace errors).
WSDL validation in Woden includes schema validation (if supported by the
xml parser) and checking of the WSDL object model by the Woden validator.
Terminating errors in Woden include configuration errors and parser
exceptions such as DOMException. These will be wrapped, if necessary, and
thrown as WSDLExceptions and any in-progress parsing will stop.
Non-terminating errors are parse-time WSDL errors from which we can
continue, even if we can't build the complete wsdl model.
Unless terminating errors are encountered when parsing the WSDL, we should
try to create as much of the wsdl model as we can, even if we end up with a
partially complete wsdl model. If wsdl validation is turned on in Woden,
report the parse-time errors and carry on completing as much of the model
as possible. If validation is turned off, carry on creating the model if
possible without reporting the errors. One usage scenario for creating a
partially complete wsdl model with parse-time validation turned off is when
a WSDL editing tool is being used to work on an incomplete WSDL document
and the WSDL only gets validated when requested by the user.
TODO - consider the scenario where a runtime system may run with validation
turned off for performance - here, a parse-time error should probably
terminate with a WSDLException, not return a partially complete model.
Consider how to distinguish this scenario from the WSDL editor scenario
above (perhaps via reader configuration features)
For now, report any non-terminating, parse-time errors as they occur (e.g.
qname namespace resolution errors, xml parser warnings and non-fatal
errors). Later we can decide if these error messages should be cached at
parse-time and handled by the validator instead.
We will need a mechanism to determine at the end of the parse if any errors
have been reported either by Woden or by the xml parser so as not to
continue on with validating the Component model (i.e. report and fix the
known errors in the xml first).
In the xml-based wsdl model represented by the org.apache.woden.wsdl20.xml
interfaces (i.e. the xxxElement interfaces), we should base element
references on real xxxElement objects, not QNames or prefixed name strings.
For example, BindingElement should represent the <binding> element's
'interface' attribute with a reference to an InterfaceElement object (not
to its QName object).
We need to capture at parse-time the line/column numbers for the start tag
of each wsdl element. These are used by the ErrorReporter. We also plan to
use them for calculating offsets to pinpoint errors at a more fine-grained
level (e.g. error reporting that highlights particular attributes or
attribute values).
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: Plan to handle parsing errors and validation.
Posted by Kihup Boo <kb...@ca.ibm.com>.
> they occur. If a namespace error does occur, create the QName with a ""
> (empty string) namespace and whatever the local part and prefix are in
the
> xml. An empty string namespace will indicate to the Woden validator that
a
> namespace error exists for that QName. Note that unqualified names in the
What about making the namespace error more explicit in the QName?
For example, using something like
"http://www.woden.org/unresolved-namespace-error/" instead of using "".
This way, users of the model might be able to make a better guess when the
error happens without learning the empty string namespace.
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
10/12/2005 05:54 cc
AM
Subject
Plan to handle parsing errors and
Please respond to validation.
woden-dev
Yesterday I discussed the qname issue and other validation issues with
Lawrence. This is a summary of how we plan to progress for milestone 2.
Any comments or suggestions are welcome.
Don't store the string values of attributes with prefixed names (as
proposed in John Kaputin's earlier posting). Resolve the namespaces and
create QNames at parse-time, reporting any namespace resolution errors as
they occur. If a namespace error does occur, create the QName with a ""
(empty string) namespace and whatever the local part and prefix are in the
xml. An empty string namespace will indicate to the Woden validator that a
namespace error exists for that QName. Note that unqualified names in the
WSDL will have the default namespace so the QName created will have a
namespace value equal to the default namespace, a local part equal to the
unqualified name and a prefix of "" (i.e. it won't use "" in the namespace
field, so we can use the "" convention described here for indicating QName
namespace errors).
WSDL validation in Woden includes schema validation (if supported by the
xml parser) and checking of the WSDL object model by the Woden validator.
Terminating errors in Woden include configuration errors and parser
exceptions such as DOMException. These will be wrapped, if necessary, and
thrown as WSDLExceptions and any in-progress parsing will stop.
Non-terminating errors are parse-time WSDL errors from which we can
continue, even if we can't build the complete wsdl model.
Unless terminating errors are encountered when parsing the WSDL, we should
try to create as much of the wsdl model as we can, even if we end up with a
partially complete wsdl model. If wsdl validation is turned on in Woden,
report the parse-time errors and carry on completing as much of the model
as possible. If validation is turned off, carry on creating the model if
possible without reporting the errors. One usage scenario for creating a
partially complete wsdl model with parse-time validation turned off is when
a WSDL editing tool is being used to work on an incomplete WSDL document
and the WSDL only gets validated when requested by the user.
TODO - consider the scenario where a runtime system may run with validation
turned off for performance - here, a parse-time error should probably
terminate with a WSDLException, not return a partially complete model.
Consider how to distinguish this scenario from the WSDL editor scenario
above (perhaps via reader configuration features)
For now, report any non-terminating, parse-time errors as they occur (e.g.
qname namespace resolution errors, xml parser warnings and non-fatal
errors). Later we can decide if these error messages should be cached at
parse-time and handled by the validator instead.
We will need a mechanism to determine at the end of the parse if any errors
have been reported either by Woden or by the xml parser so as not to
continue on with validating the Component model (i.e. report and fix the
known errors in the xml first).
In the xml-based wsdl model represented by the org.apache.woden.wsdl20.xml
interfaces (i.e. the xxxElement interfaces), we should base element
references on real xxxElement objects, not QNames or prefixed name strings.
For example, BindingElement should represent the <binding> element's
'interface' attribute with a reference to an InterfaceElement object (not
to its QName object).
We need to capture at parse-time the line/column numbers for the start tag
of each wsdl element. These are used by the ErrorReporter. We also plan to
use them for calculating offsets to pinpoint errors at a more fine-grained
level (e.g. error reporting that highlights particular attributes or
attribute values).
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