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" <gcowe@origoservices.com>
To: "Pete Cordell" <petexmldev@tech-know-ware.com>
Cc: <public-xsd-databinding@w3.org>
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: public-xsd-databinding-request@w3.org 
[mailto:public-xsd-databinding-request@w3.org] On Behalf Of Pete Cordell
Sent: 08 June 2007 12:12
To: public-xsd-databinding@w3.org
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.

Received on Friday, 15 June 2007 09:12:47 UTC