Subject:Unwanted blanks in XML schema / XSD to XML conversion Author:(Deleted User) Date:20 Oct 2005 10:10 AM
We don't have an option to turn off number padding.
Can I ask you why you think this is a problem?
I was under impression that this will give user
an idea how many digits he/she can use when replacing
sample number with some actual value in generated XML.
I can of cause change it to fill unused slots with "0" or "1"
instead of spaces...
Subject:Unwanted blanks in XML schema / XSD to XML conversion Author:Bruno F Date:20 Oct 2005 11:50 AM
Its a formal requirement on how we test our software product.
For the test we need synthetic data that looks like real data - which won't feature padding.
The proble is that the resulting number has 13 digits, whereas the restriction was set to 12 digits.
Some engines ignore the leading zeros, some don't and report an error.
Anyway, I think that padding should not put too much zeros or is there a reason that this is desired functionality?
It would be really nice to have an "Option"-Switch for padding anyways.
"The term totalDigits is chosen to reflect the fact that it restricts
the ·value space· to those values that can be represented lexically
using at most totalDigits digits. Note that it does not restrict the
·lexical space· directly; a lexical representation that adds additional
leading zero digits or trailing fractional zero digits is still
permitted."
Subject:Unwanted blanks in XML schema / XSD to XML conversion Author:Bruno F Date:09 Jan 2006 01:30 PM
Thanks for the quick reply, Tony.
I agree there might be more critical issues to look into :) ... I just wanted to remark that the number padding in this case fails to deliver the proposed functionality. According to Yuriy, the padding was introduced to allow users to quickly edit the XML instance without looking into the XSD.
Subject:Unwanted blanks in XML schema / XSD to XML conversion (padding) Author:Bruno F Date:10 Jan 2006 05:19 AM
*rofl*
sounds good... especially because I just came across a couple of issues on which I would greatly appreciate your opinion.
I'm still concerned with the "XML Schema to XML"-Functionality.
Issues:
- Generated XML is not valid when mutliple facets apply (esp. a regular expression pattern and minInclusive/maxInclusive)
- Generated XML depends on the order of restriction facets (below cases put the pattern first and last, respectively)
- Number padding is not working for these cases (minor issue).
I am currently working on a project where we have to deal with a large amount of complex schemata featuring stuff like you see below. I need to regularly create XML instances...
Here are XSD Samples and XML generated by StylusStudio. Both are reported invalid by StylusStudio.
Subject:Unwanted blanks in XML schema / XSD to XML conversion (padding) Author:Bruno F Date:17 Jan 2006 10:07 AM
Hi Tony,
hopefully you found the input helpful.
will there be an update to the XML instance generation?
That functionality was the main reason we bought StylusStudio... on my recommendation, since its already doing better on regular expressions than *thenamethatmaynotbespoken* :)
Subject:Unwanted blanks in XML schema / XSD to XML conversion (padding) Author:Tony Lavinio Date:17 Jan 2006 11:28 AM
First, the spec says we can add as many zeros as we want.
But we want to be nice and play well with others, to we
try to generate the same number as the totalDigits=.
In your case, there was a very interesting interaction going
on. When we generated the sample number, you asked for 13
digits. The datatype was integer, and the largest positive
value that an integer can hold is 12 digits. If you go bigger,
you wrap (due to twos-complements math) to negatives. And
that's what happened. The internal function saw that the output
was 13 characters (12 digits plus the '-') and formatted the
output field to 13 spaces.
The good news is that this will be changed in the next release.
The bad news is that since we are well within the explicit text
of the specification, this will not be backported into a patch
for the current release.
Subject:Unwanted blanks in XML schema / XSD to XML conversion (padding) Author:Bruno F Date:17 Jan 2006 11:42 AM
So you're saying no patch to StylusStudio Professional 2006 considering the "too much zeroes" issues. This one is minor...I can live with it :)
But what about the two sample XSDs and the related issues? StylusStudio isnt producing valid XML for these... this might be a more serious gap in functionality (not to say a bug). I'd call it the "multiple restriction facets" issue.
Or am I off-topic here and we should move the discussion somewhere else *g*.
Subject:Unwanted blanks in XML schema / XSD to XML conversion (padding) Author:Tony Lavinio Date:17 Jan 2006 02:42 PM
It turns out that there is no algorithm that will guarantee that the
generated XML will match the schema that will run in predictable time.
Our algorithm is highly tuned, but unless we start writing all sorts
of special-case code for specific situations, it's unlikely that it
will improve to the point where we can guarantee that for any valid
XSD we will generate a perfectly valid XML file. We're also pretty
sure that no one else can guarantee it in all cases.
We are proud of the generator we have; we feel it's about as good as
we or anyone else is likely to make in general (there may be specific
cases where another works better).
Just as a simple example, it doesn't take too much effort to build a
regular expression pattern facet that will take hours of iteration to
build a string that will pass.
There comes a point where nothing beats a sample of real data, and you
are probably right at that point.
Sorry we couldn't do more; at least the padding issue will be solved
in the next release (although I still do not admit guilt there ;) ).