Comments on test cases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Comments on test cases

Pete Cordell

I've been working through the various test cases.  I still have to resolve
some issues (such as handling xs:include in the tests etc.), but I thought
I'd report back some things I have found.

As our tool is very much a schema tool, I'm using the .xsd files rather than
the .wsdl files, or the various echo*.* files.

Firstly, I'm impressed by how much work you have done.

- In floatElement and the various float tests, the default and enumerated
values actually have more decimal digits than can be captured by a single
precision value.  This makes round tripping difficult.  For example, when
1267.43233E12 is input, our tool outputs 1.267432e+15 (7 digits of
precision, which I believe if right for a single precision floating point
number - 23 bits?).

Some of the problem here is that our XML comparison tool is not schema
aware.  So it looks at the two values, sees they're not lexically identical,
and then says "well, maybe they're floating point numbers".  The trouble is,
our comparison tool, being C++, converts both numbers to doubles, at which
precision the two numbers are different.

Obviously if you have a better comparison tool you can get around this.  But
I still feel if you are testing single precision floating point values,
you're literals should be exactly representable at that precision.

- In the globalStringAttribute schema I believe the reference to the global
attribute needs a namespace prefix (e.g. ref="ex:...").

I'm not sure if these instances are supposed to be wrong but...

- The QualifiedLocalElements01.xml instance looks wrong to me.  Needs to be
<ex:qualifiedLocalElements ... unless the instance meant to define a default
namespace.

- ElementDefault-ElementDefault04.xml looks wrong.  'anotherValue' can not
appear without being wrapped in <text> tags.

- For the non-SOAP XML instances there are a lot of redundant soap and wsdl
namespace prefixes set up.  I assume these are as a result of generating the
instances from some master input.  It's not a big issue, but if they weren't
present it would look prettier!

That's all for now.  I may have more later.

Regards,

Pete.

P.S. Our company name has changed, hence the different sig
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================



Reply | Threaded
Open this post in threaded view
|

RE: Comments on test cases

origogeo

Thanks for the comments Pete.

I'll attempt to give an answer to each of your points -

Float/Double.
Our examples are taken from XML Schema Part 2 Datatypes http://www.w3.org/TR/xmlschema-2/#float
where it states that
"For example, -1E4, 1267.43233E12, 12.78e-2, 12 , -0, 0 and INF are all legal literals for float."
So we would expect data binding tools to support these values.

GlobalStringAttribute.
I don't think we have a globalStringAttribute schema so I'm not sure about the issue you mention regarding this - can you point me to the particular page? All our examples are based on this master file http://www.w3.org/2002/ws/databinding/edcopy/patterns/examples.xml


QualifiedLocalElements01.xml
Yes - well spotted, this should actually have a namespace prefix specified - we will correct this.

LocalElementDefault
http://www.w3.org/2002/ws/databinding/examples/6/09/LocalElementDefault/LocalElementDefault-LocalElementDefault04.xml
It looks like the example has already been corrected. The value is wrapped in a <text> element now.

Soap and wsdl namespace prefixes.
All our instances are generated from the examples.xml http://www.w3.org/2002/ws/databinding/examples/6/09/examples.xml
As you will see this contains all the namespaces which make their way into the instances via a series of transformations http://www.w3.org/2002/ws/databinding/edcopy/patterns/
We just haven't got round to optimizing these yet.

Once again thanks for your comments and keep them coming!

Regards
George
     

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Pete Cordell
Sent: 08 June 2007 12:12
To: [hidden email]
Subject: Comments on test cases


I've been working through the various test cases.  I still have to resolve
some issues (such as handling xs:include in the tests etc.), but I thought
I'd report back some things I have found.

As our tool is very much a schema tool, I'm using the .xsd files rather than
the .wsdl files, or the various echo*.* files.

Firstly, I'm impressed by how much work you have done.

- In floatElement and the various float tests, the default and enumerated
values actually have more decimal digits than can be captured by a single
precision value.  This makes round tripping difficult.  For example, when
1267.43233E12 is input, our tool outputs 1.267432e+15 (7 digits of
precision, which I believe if right for a single precision floating point
number - 23 bits?).

Some of the problem here is that our XML comparison tool is not schema
aware.  So it looks at the two values, sees they're not lexically identical,
and then says "well, maybe they're floating point numbers".  The trouble is,
our comparison tool, being C++, converts both numbers to doubles, at which
precision the two numbers are different.

Obviously if you have a better comparison tool you can get around this.  But
I still feel if you are testing single precision floating point values,
you're literals should be exactly representable at that precision.

- In the globalStringAttribute schema I believe the reference to the global
attribute needs a namespace prefix (e.g. ref="ex:...").

I'm not sure if these instances are supposed to be wrong but...

- The QualifiedLocalElements01.xml instance looks wrong to me.  Needs to be
<ex:qualifiedLocalElements ... unless the instance meant to define a default
namespace.

- ElementDefault-ElementDefault04.xml looks wrong.  'anotherValue' can not
appear without being wrapped in <text> tags.

- For the non-SOAP XML instances there are a lot of redundant soap and wsdl
namespace prefixes set up.  I assume these are as a result of generating the
instances from some master input.  It's not a big issue, but if they weren't
present it would look prettier!

That's all for now.  I may have more later.

Regards,

Pete.

P.S. Our company name has changed, hence the different sig
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================




E-mail disclaimer

The information in this e-mail is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission and then delete this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.

Origo Services Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or the contents.  It is your responsibility to scan for viruses.  Origo Services Limited reserves the right to monitor e-mails sent to or from addresses under its control.  When you reply to this e-mail, you are consenting to Origo Services Limited monitoring the content of the e-mails you send to or receive from Origo Services Limited.  If this e-mail is non-business related Origo Services Limited is not liable for any opinions expressed by the sender.  The contents of this e-mail are protected by copyright.  All rights reserved.

Origo Services Limited is a company incorporated in Scotland (company number 115061) having its registered office at 4th floor, Saltire Court, 20 Castle Terrace, Edinburgh EH1 2EN.


Reply | Threaded
Open this post in threaded view
|

Re: Comments on test cases

Pete Cordell

Thanks George.

The only thing I have issue with is the float one.
1267.43233765876583765E12 is also a legal literal for a float, but that
doesn't mean that it can be fully represented in a float variable, and thus
not round-trippable.

I notice that for some of the Java test results are not lexically
equivalent, but have passed.  But I think it would be nice from a debugging
point of view if a value was chosen that could be round tripped and compared
lexically by a human without an IEEE 754 brain implant!  Or you could use a
comparison tool that wasn't schema aware.

(Interestingly my C++ library (VS2005) records FLT_DIG (the # of decimal
digits of precision) to be 6.  I'm not sure of the significance of that!)

(Re: GlobalStringAttribute - I used the directory tree from the zip file as
my source of schemas to parse.  Maybe this one never got formally accepted.)

Thanks again,

Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================

----- Original Message -----
From: "George Cowe" <[hidden email]>
To: "Pete Cordell" <[hidden email]>
Cc: <[hidden email]>
Sent: Friday, June 15, 2007 8:37 AM
Subject: RE: Comments on test cases


Thanks for the comments Pete.

I'll attempt to give an answer to each of your points -

Float/Double.
Our examples are taken from XML Schema Part 2 Datatypes
http://www.w3.org/TR/xmlschema-2/#float
where it states that
"For example, -1E4, 1267.43233E12, 12.78e-2, 12 , -0, 0 and INF are all
legal literals for float."
So we would expect data binding tools to support these values.

GlobalStringAttribute.
I don't think we have a globalStringAttribute schema so I'm not sure about
the issue you mention regarding this - can you point me to the particular
page? All our examples are based on this master file
http://www.w3.org/2002/ws/databinding/edcopy/patterns/examples.xml


QualifiedLocalElements01.xml
Yes - well spotted, this should actually have a namespace prefix specified -
we will correct this.

LocalElementDefault
http://www.w3.org/2002/ws/databinding/examples/6/09/LocalElementDefault/LocalElementDefault-LocalElementDefault04.xml
It looks like the example has already been corrected. The value is wrapped
in a <text> element now.

Soap and wsdl namespace prefixes.
All our instances are generated from the examples.xml
http://www.w3.org/2002/ws/databinding/examples/6/09/examples.xml
As you will see this contains all the namespaces which make their way into
the instances via a series of transformations
http://www.w3.org/2002/ws/databinding/edcopy/patterns/
We just haven't got round to optimizing these yet.

Once again thanks for your comments and keep them coming!

Regards
George


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Pete Cordell
Sent: 08 June 2007 12:12
To: [hidden email]
Subject: Comments on test cases


I've been working through the various test cases.  I still have to resolve
some issues (such as handling xs:include in the tests etc.), but I thought
I'd report back some things I have found.

As our tool is very much a schema tool, I'm using the .xsd files rather than
the .wsdl files, or the various echo*.* files.

Firstly, I'm impressed by how much work you have done.

- In floatElement and the various float tests, the default and enumerated
values actually have more decimal digits than can be captured by a single
precision value.  This makes round tripping difficult.  For example, when
1267.43233E12 is input, our tool outputs 1.267432e+15 (7 digits of
precision, which I believe if right for a single precision floating point
number - 23 bits?).

Some of the problem here is that our XML comparison tool is not schema
aware.  So it looks at the two values, sees they're not lexically identical,
and then says "well, maybe they're floating point numbers".  The trouble is,
our comparison tool, being C++, converts both numbers to doubles, at which
precision the two numbers are different.

Obviously if you have a better comparison tool you can get around this.  But
I still feel if you are testing single precision floating point values,
you're literals should be exactly representable at that precision.

- In the globalStringAttribute schema I believe the reference to the global
attribute needs a namespace prefix (e.g. ref="ex:...").

I'm not sure if these instances are supposed to be wrong but...

- The QualifiedLocalElements01.xml instance looks wrong to me.  Needs to be
<ex:qualifiedLocalElements ... unless the instance meant to define a default
namespace.

- ElementDefault-ElementDefault04.xml looks wrong.  'anotherValue' can not
appear without being wrapped in <text> tags.

- For the non-SOAP XML instances there are a lot of redundant soap and wsdl
namespace prefixes set up.  I assume these are as a result of generating the
instances from some master input.  It's not a big issue, but if they weren't
present it would look prettier!

That's all for now.  I may have more later.

Regards,

Pete.

P.S. Our company name has changed, hence the different sig
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================




E-mail disclaimer

The information in this e-mail is sent in confidence for the addressee only
and may be legally privileged. Unauthorised recipients must preserve this
confidentiality and should please advise the sender immediately of the error
in transmission and then delete this e-mail. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken in
reliance on its content is prohibited and may be unlawful.

Origo Services Limited accepts no responsibility for any loss or damage
resulting directly or indirectly from the use of this e-mail or the
contents.  It is your responsibility to scan for viruses.  Origo Services
Limited reserves the right to monitor e-mails sent to or from addresses
under its control.  When you reply to this e-mail, you are consenting to
Origo Services Limited monitoring the content of the e-mails you send to or
receive from Origo Services Limited.  If this e-mail is non-business related
Origo Services Limited is not liable for any opinions expressed by the
sender.  The contents of this e-mail are protected by copyright.  All rights
reserved.

Origo Services Limited is a company incorporated in Scotland (company number
115061) having its registered office at 4th floor, Saltire Court, 20 Castle
Terrace, Edinburgh EH1 2EN.




Reply | Threaded
Open this post in threaded view
|

Re: Comments on test cases

Ed Day-2

> The only thing I have issue with is the float one.
> 1267.43233765876583765E12 is also a legal literal for a float, but that
> doesn't mean that it can be fully represented in a float variable, and
> thus not round-trippable.

Many data binding tools provide a way to configure the native language type
that is used to hold a given data item.  In this case, the type to hold this
item can be configured to be a string which would allow the item to be
round-tripped.

HTH

Ed Day
Objective Systems, Inc.
http://www.obj-sys.com


----- Original Message -----
From: "Pete Cordell" <[hidden email]>
To: "George Cowe" <[hidden email]>
Cc: <[hidden email]>
Sent: Friday, June 15, 2007 5:12 AM
Subject: Re: Comments on test cases


>
> Thanks George.
>
> The only thing I have issue with is the float one.
> 1267.43233765876583765E12 is also a legal literal for a float, but that
> doesn't mean that it can be fully represented in a float variable, and
> thus not round-trippable.
>
> I notice that for some of the Java test results are not lexically
> equivalent, but have passed.  But I think it would be nice from a
> debugging point of view if a value was chosen that could be round tripped
> and compared lexically by a human without an IEEE 754 brain implant!  Or
> you could use a comparison tool that wasn't schema aware.
>
> (Interestingly my C++ library (VS2005) records FLT_DIG (the # of decimal
> digits of precision) to be 6.  I'm not sure of the significance of that!)
>
> (Re: GlobalStringAttribute - I used the directory tree from the zip file
> as my source of schemas to parse.  Maybe this one never got formally
> accepted.)
>
> Thanks again,
>
> Pete.
> --
> =============================================
> Pete Cordell
> Codalogic Ltd
> for XML Schema to C++ data binding visit
> http://www.codalogic.com/lmx/
> =============================================
>
> ----- Original Message -----
> From: "George Cowe" <[hidden email]>
> To: "Pete Cordell" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Friday, June 15, 2007 8:37 AM
> Subject: RE: Comments on test cases
>
>
> Thanks for the comments Pete.
>
> I'll attempt to give an answer to each of your points -
>
> Float/Double.
> Our examples are taken from XML Schema Part 2 Datatypes
> http://www.w3.org/TR/xmlschema-2/#float
> where it states that
> "For example, -1E4, 1267.43233E12, 12.78e-2, 12 , -0, 0 and INF are all
> legal literals for float."
> So we would expect data binding tools to support these values.
>
> GlobalStringAttribute.
> I don't think we have a globalStringAttribute schema so I'm not sure about
> the issue you mention regarding this - can you point me to the particular
> page? All our examples are based on this master file
> http://www.w3.org/2002/ws/databinding/edcopy/patterns/examples.xml
>
>
> QualifiedLocalElements01.xml
> Yes - well spotted, this should actually have a namespace prefix
> specified - we will correct this.
>
> LocalElementDefault
> http://www.w3.org/2002/ws/databinding/examples/6/09/LocalElementDefault/LocalElementDefault-LocalElementDefault04.xml
> It looks like the example has already been corrected. The value is wrapped
> in a <text> element now.
>
> Soap and wsdl namespace prefixes.
> All our instances are generated from the examples.xml
> http://www.w3.org/2002/ws/databinding/examples/6/09/examples.xml
> As you will see this contains all the namespaces which make their way into
> the instances via a series of transformations
> http://www.w3.org/2002/ws/databinding/edcopy/patterns/
> We just haven't got round to optimizing these yet.
>
> Once again thanks for your comments and keep them coming!
>
> Regards
> George
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Pete Cordell
> Sent: 08 June 2007 12:12
> To: [hidden email]
> Subject: Comments on test cases
>
>
> I've been working through the various test cases.  I still have to resolve
> some issues (such as handling xs:include in the tests etc.), but I thought
> I'd report back some things I have found.
>
> As our tool is very much a schema tool, I'm using the .xsd files rather
> than
> the .wsdl files, or the various echo*.* files.
>
> Firstly, I'm impressed by how much work you have done.
>
> - In floatElement and the various float tests, the default and enumerated
> values actually have more decimal digits than can be captured by a single
> precision value.  This makes round tripping difficult.  For example, when
> 1267.43233E12 is input, our tool outputs 1.267432e+15 (7 digits of
> precision, which I believe if right for a single precision floating point
> number - 23 bits?).
>
> Some of the problem here is that our XML comparison tool is not schema
> aware.  So it looks at the two values, sees they're not lexically
> identical,
> and then says "well, maybe they're floating point numbers".  The trouble
> is,
> our comparison tool, being C++, converts both numbers to doubles, at which
> precision the two numbers are different.
>
> Obviously if you have a better comparison tool you can get around this.
> But
> I still feel if you are testing single precision floating point values,
> you're literals should be exactly representable at that precision.
>
> - In the globalStringAttribute schema I believe the reference to the
> global
> attribute needs a namespace prefix (e.g. ref="ex:...").
>
> I'm not sure if these instances are supposed to be wrong but...
>
> - The QualifiedLocalElements01.xml instance looks wrong to me.  Needs to
> be
> <ex:qualifiedLocalElements ... unless the instance meant to define a
> default
> namespace.
>
> - ElementDefault-ElementDefault04.xml looks wrong.  'anotherValue' can not
> appear without being wrapped in <text> tags.
>
> - For the non-SOAP XML instances there are a lot of redundant soap and
> wsdl
> namespace prefixes set up.  I assume these are as a result of generating
> the
> instances from some master input.  It's not a big issue, but if they
> weren't
> present it would look prettier!
>
> That's all for now.  I may have more later.
>
> Regards,
>
> Pete.
>
> P.S. Our company name has changed, hence the different sig
> --
> =============================================
> Pete Cordell
> Codalogic Ltd
> for XML Schema to C++ data binding visit
> http://www.codalogic.com/lmx/
> =============================================
>
>
>
>
> E-mail disclaimer
>
> The information in this e-mail is sent in confidence for the addressee
> only and may be legally privileged. Unauthorised recipients must preserve
> this confidentiality and should please advise the sender immediately of
> the error in transmission and then delete this e-mail. If you are not the
> intended recipient, any disclosure, copying, distribution or any action
> taken in reliance on its content is prohibited and may be unlawful.
>
> Origo Services Limited accepts no responsibility for any loss or damage
> resulting directly or indirectly from the use of this e-mail or the
> contents.  It is your responsibility to scan for viruses.  Origo Services
> Limited reserves the right to monitor e-mails sent to or from addresses
> under its control.  When you reply to this e-mail, you are consenting to
> Origo Services Limited monitoring the content of the e-mails you send to
> or receive from Origo Services Limited.  If this e-mail is non-business
> related Origo Services Limited is not liable for any opinions expressed by
> the sender.  The contents of this e-mail are protected by copyright.  All
> rights reserved.
>
> Origo Services Limited is a company incorporated in Scotland (company
> number 115061) having its registered office at 4th floor, Saltire Court,
> 20 Castle Terrace, Edinburgh EH1 2EN.
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Comments on test cases

Pete Cordell

----- Original Message From: "Ed Day" <[hidden email]>

>> The only thing I have issue with is the float one.
>> 1267.43233765876583765E12 is also a legal literal for a float, but that
>> doesn't mean that it can be fully represented in a float variable, and
>> thus not round-trippable.
>
> Many data binding tools provide a way to configure the native language
> type that is used to hold a given data item.  In this case, the type to
> hold this item can be configured to be a string which would allow the item
> to be round-tripped.


Hi Ed,

That's true, but I don't think that's in the spirit of the tests.

The original test could be more honestly passed by setting the mapped type
to a double, but even that seems against the spirit of the test to me.

Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================



Reply | Threaded
Open this post in threaded view
|

Re: Comments on test cases

Ed Day-2

I think the issue of preserving the format of floating point numbers when
encoded is problematic for most data binding tools.  It really depends on
what the end user expects.  If he expects the number to come back out in the
same format it went in as, about the only practical way to do it is to use a
string.  The alternative would be to store all kinds of numeric format
information along with the floating point value when it is decoded.

Regards,

Ed

----- Original Message -----
From: "Pete Cordell" <[hidden email]>
To: "Ed Day" <[hidden email]>; "George Cowe" <[hidden email]>
Cc: <[hidden email]>
Sent: Friday, June 15, 2007 10:09 AM
Subject: Re: Comments on test cases


> ----- Original Message From: "Ed Day" <[hidden email]>
>
>>> The only thing I have issue with is the float one.
>>> 1267.43233765876583765E12 is also a legal literal for a float, but that
>>> doesn't mean that it can be fully represented in a float variable, and
>>> thus not round-trippable.
>>
>> Many data binding tools provide a way to configure the native language
>> type that is used to hold a given data item.  In this case, the type to
>> hold this item can be configured to be a string which would allow the
>> item
>> to be round-tripped.
>
>
> Hi Ed,
>
> That's true, but I don't think that's in the spirit of the tests.
>
> The original test could be more honestly passed by setting the mapped type
> to a double, but even that seems against the spirit of the test to me.
>
> Pete.
> --
> =============================================
> Pete Cordell
> Codalogic Ltd
> for XML Schema to C++ data binding visit
> http://www.codalogic.com/lmx/
> =============================================
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Comments on test cases

Pete Cordell
In reply to this post by Pete Cordell
----- Original Message From: "Pete Cordell" <[hidden email]>
> The only thing I have issue with is the float one.
> 1267.43233765876583765E12 is also a legal literal for a float, but that
> doesn't mean that it can be fully represented in a float variable, and
> thus not round-trippable.

I've been doing some more tests of this...

If I store 1267.43233E12 in a float, then write it to strings using both 7
and 8 digit precision, and then read those strings back to floats, (see
attached code) I find that the value converted at 7 digit precision doesn't
match the input, whereas the value converted at 8 digit precision does.

This points to 8 digits of precision being the way to go.

BUT if I build up all the strings such as 0.1, 0.2, 0.3, up to 0.9999999,
read them into a float and then print that float to strings at 7 and 8
digits of precision, every time the 7 digit conversion gets the same text
output as the input, whereas nearly 70% of the time extra extraneous digits
are produced when using 8 digits of precision.

For example, you get results like:
input   7-digit    8-digit
0.1     0.1         0.1
0.2     0.2         0.2
0.3     0.3  0.30000001
0.4     0.4  0.40000001
0.5     0.5         0.5
0.6     0.6  0.60000002
0.7     0.7  0.69999999
0.8     0.8  0.80000001
0.9     0.9  0.89999998
0.1     0.1         0.1
0.11    0.11        0.11
0.12    0.12        0.12
0.13    0.13        0.13
0.14    0.14        0.14
0.15    0.15  0.15000001
0.16    0.16        0.16
0.17    0.17        0.17
0.18    0.18  0.18000001

That says to me that 7 digits is the correct way to go.

So there's a judgement call to be made here.  Go with 8 and pass the W3C
test but surprise your customers with strange results, or go with 7 and fail
the W3C test, but give results your customers probably expect.

As customers, if they really care about this sort of precision, have the
option to map xs:float to double, I've decided to go with 7 digits of
precision and fail the test.

This seems unfortunate to me.  The intent of the test seems to be about
whether floating point numbers can be parsed and generated, not about corner
cases in IEEE 754 binary to text conversion.  There are a vast number of
values that could be used that would round-trip perfectly.  Why stick with a
value that an editor created by dancing across his/her keyboard if it causes
problem?

Regards,

Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================

float-precision.cpp (1K) Download Attachment