| rip |
| Advanced Member |
|
| Minutiae, Triviality |
|
|
| None Specified |
|
| Thursday, July 17, 2008 |
| Thursday, October 2, 2014 4:23:07 PM |
185
[1.02% of all post / 0.03 posts per day] |
|
1) post-pend a 400 space long string to your input, substring the input to exactly 400 characters
2) Use a recursive function to add 25-space long chunks to the input until it passes 400 characters, then substring it to 400 characters
input -> concat(input, " ") -> string-length() -> is > 400?
YES: return substring(input, 400),
NO: recursively call self(input)
The use of #2, where you also supply the desired length (400 in this case), makes this a general purpose solution.
rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
Thanks, Vlad, that's sorted it.
I'd been trying with ancestor:: but couldn't stumble on the correct syntax.
[=AutoCalc]: [fnorb>(content)<fnorb]
with the AutoCalc xpath set to string-join( ('', ancester::foo/@name), '/' )
to get the exact output
/one/two/...: hydrogen
/one/two/...: helium
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
Brute forced it using a design fragment, effectively
if (exists(../../../../foo)) then concat("/", ../../../../@name) else ''
if (exists(../../../foo)) then concat("/", ../../../@name) else ''
if (exists(../../foo)) then concat("/", ../../@name) else ''
if (exists(../foo)) then concat("/", ../@name) else ''
since I know that it will never be more than four deep.
Still there should be a way to do this using a recursive template.
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
I have an xsd that allows:
Code:<foo name="one">
<foo name="two">
<foo name="...">
<bar>
<fnorb>hydrogen</fnorb>
</bar>
<bar>
<fnorb>helium</fnorb>
<bar>
</foo>
...
</foo>
ie, an arbitrarily deep set of @name'd 'foo' elements with a sequence of bar elements innermost.
I'm trying for a finely crafted autocalc xpath that will return a concat xs:string value of /one/two/... for an arbitrary 'bar' element. The display would result in something like:
/one/two/...: hydrogen
/one/two/...: helium
Suggestions?
tia,
rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
vlad wrote:It is actually not so difficult as one could imagine. ....
I didn't say difficult, I said clunky. Clunky means you can do it, it's just going to be sub-optimal, slow, brute forced, brittle, it won't scale etc.
Do it externally in C++ or Java, this is the use case (single input, single output) that custom user defined functions are designed for.
And you can put both a hex converter and a base 64 (or base 30 or base 22 or base 120 etc) converter in the same source file.
rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
I'm assuming you have a string value "32" and are trying to get a string value "0x20" ?
It'll be quicker to write that in some underlying language (Java, C++, etc) and then use it as a custom user defined function. Perfect use case.
Using MapForce directly will be clunky.
rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
A MapForce map can easily be generated that does these things.
MapForce isn't just a data mediation tool, it's also a meta-data inspection tool (although it isn't marketed as such).
Regards,
Rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
I mean use different XSDs, maintain a local version with that change.
Explain to them that if they can't change the XSD, then it means you will have to address -- in the code -- the disconnect between what they want and what they have.
If they say "so be it! fix your code!" you generate a second XSD that replaces the xs:integer with an xs:string and a set of pattern facets that ensures that what they get is the same as what they want, and then check that XSD in and document exactly why you have a forked XSD and show exactly what excess work it is generating for you, and also document what changes you need to make (hopefully there is only the one place). So that when someone else issues a change order to change the XSD, you know where to go in the new version to re-implement the fork and check in the new version.
Then, fix the code so that it does what they want. If you are using XMLSpy to generate bindings for the XSD, do so with your locally changed XSD. If done correctly, the generated XML files will evaluate correctly against either XSD.
Also... if the XSD changes periodically, stand up and say "look, we are changing the XSD periodically. Let's fix this since it's changing anyway."
Really, "xs:integer" here is borked. That field should be a xs:string because they are codes, not integers.
rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
opinion:
Well, on the face of it, an INDUSCodeType /is not an integer/. It's an ASCII-numeric code.
The other groups are wrong. Basing it off of xs:integer? That's just lazy.
An XSD is used to validate an XML file for correctness. If the XML file validates, that's great. How you choose to manipulate teh data internally at runtime after parsing is entirely up to the application.
The problem I expect you are having is that when you generate an internal DOM from the XSD, populate it, and then express it as XML, you get
<INDUSCodeType>37</INDUSCodeType>
because that's what the XSD is set up for, and that's what the XML-emitter is going to do (and, since 000037 and 37 are equal in the eyes of xs:integer).
options:
1) keep an internal version of the XSD that redefines that as xs:string. Use that in your generated code (for data in memory).
2) Have a MapForce map that simply prepends any integer in that field with sufficient "0" to make it acceptable to third parties' usage (for data at rest, eg in a file or such).
3) Try harder to convince the 3d parties they are lazy and wrong.
May be others.
go 9ers!
rip
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
duplicate question to https://www.altova.com/forum/default.aspx?g=posts&t=1100000142
--
Remember to check the date on this post, as the information contained may be superseded, be fixed or be no longer relevant.
|
|
