In response to: The On-Line Encyclopedia of Integer Sequences® (OEIS®) gets 50
I added the proof at end of previous blog posting as well, soo easy!
HermannSW 2700006U54 Tags:  oeis encyclopedia integer online mathematica sequence wolframalpha 1,465 Views
In response to: The On-Line Encyclopedia of Integer Sequences® (OEIS®) gets 50
XInclude (XML Inclusions) is a big spec that never got much adoption, at least partly because dependent on XPointer spec:
A customer wanted to know why XInclude does not work on DataPower.
Simple answer is that it is not listed under "Supported standards and protocols", here for 6.0.0.x firmware:
(XSLT does have such mechanisms, <xsl:include> and <xsl:import>)
This is document.xml:
And here can you see that it does happen with xinclude.demo.xsl:
And this is xinclude.xsl implementing "Basic Inclusion" only from XInclude spec:
Some words of caution:
HermannSW 2700006U54 Tags:  wolframalpha oeis sequence encyclopedia online integer mathematica 1 Comment 2,310 Views
The sequence database was begun by Neil J. A. Sloane in 1964 (and is only slightly older than me).
Of course there was no world wide web at that time and the database was not "online".
OEIS contains 245636 integer sequences at the time of writing this post.
Say you have a sequence like "1,1,2,3,5,8,13" and want to know what sequences contain that as subsequnce, then you can just query OEIS. You may know that it is the start of so called "Fibonacci numbers", but OEIS does find 123 different sequences containing the given subsequence:
I am using OEIS since late 1990s, and started registering&submitting stuff myself beginning of this month:
The database is moderated and what I learned quickly by helpful comments of reviewers is that the best way to end any submission is by ". - ~~~~" (dot, space, hyphen, space, 4 tildas). The 4 tildas will be replaced by submitters name and submission date automatically.
As you can see the search sequence is highlighted in bold as every 2nd number in both sequences. Now I got the idea that the
I know that Mathematica is software for doing mathematical computations, but I neither have it nor know more.
Then I did search Google for "Mathematica online" and to my surprise found WolframAlpha allowing online execution of Mathematica formulas, see this link for the LinearRecurrence statement just mentioned:
OK, to verify that
And the proof was soooo simple, just making use of the linear recurrence from Mathematica formula.
I knew linear recurrence for the sequence I am interested in (1, 6, 37, 218, 1273, ...), it is:
As vector for that is just (7, -7, 1).
So starting with (1, 6, -6, -1, 1) I had just to end at (0, 7, 0, -7, 0, 1) by equivalance transformations for A124124;
HermannSW 2700006U54 1,805 Views
Nice, browsers do interpret overlapping elements in non well-formed HTML correctly.
This is the simple test HTML from http://stamm-wilbrandt.de/en/twitter/ub.html:
[just learned that rfc3092.txt is on "foo" and "bar"]
"circle graphs" from 1994 research publication are related to these non well-formed but "nearly" well-formed constructs.
In response to: Sum of Pascal's triangle reciprocalsApproved additions to these Online Encyclopedia of Integer Sequences (OEIS):
HermannSW 2700006U54 969 Views
Some of these toogle allow you fine grain control on what should be validated (header, fault, ...).
action used in MPGW or XML FW allows for "Validate Document via WSDL URL".
HermannSW 2700006U54 1,687 Views
This posting is on a really tricky Transform Binary stylesheet.
DataPower JSON processing with pre 188.8.131.52 firmwares is according to rfc4627.
Customer had the problem that his input "JSON" was iso-8859-1 encoded and not spec compliant.
DataPower JSON to JSONx conversion correctly complained on that:
The workaround solution was using tricky iso-8859-1.2.utf-8.binary.xsl Transform Binary stylesheet.
There is a nice online demo on that blog, too.
While it currently is not able to parse the HTML pages I am interested in, it might parse those interesting for you.
Like in previous GatewayScript postings I wanted to use htmlparser.js as module.
Not sure whether my approach is the best approach to do just that, but its simple definitely:
This is all the needs to be changed, before I did store the modified file in local: folder of appliance with coproc2 service installed:
Here you can see that demo script does correctly output 5 times true for the testcases from blog page:
And this is htmlparser.demo.js:
Last month quite some time before 184.108.40.206 firmware shipped I did coproc2gatewayscript posting here.
I made use of the fact that writing to "temporary:" folder was a possible location of a GatewayScript file.
First I was a bit frustrated, but then I realized another problem of my solution:
Also, if you look into above referenced posting, I had to make use of
in order to wait for some time (1 sec) to make sure that "temporary:///js" was written before GatewayScript action can be executed and finds the current GatewayScript file there, not a nice "hack".
The solution on how to do that was easy, just made use of Accessing XML Management interface from within a stylesheet posting.
You will have to
and that's it.
HermannSW 2700006U54 Tags:  dp:xquery-transform 1.0 datapower xquery gatewayscript firmware 2.0 220.127.116.11 xpath xslt 1,944 Views
DataPower has a XSLT 1.0 processor since day 1 long ago (1999), and that provides XPath 1.0.
With 18.104.22.168 firmware DataPower shipped XQuery 1.0 processor as well, and that provides XPath 2.0.
With 22.214.171.124 firmware released last Friday we got much new exciting stuff (I blogged on GatewayScript before).
This expression just compares false() with an empty nodeset and that is true for XPath 1.0 and false for XPath 2.0.
This XPath expresion is stored here (in order to be accessible by my and your DataPower boxes):
Now below stylesheet isXPath1.xsl does evaluate above XPath expression in a singe concat statement:
As promised this shows that XPath 1.0 and XPath 2.0 happen within a single concat statement!
Here is stylesheet isXPath1.xsl:
HermannSW 2700006U54 Tags:  draft-04 draft-03 schema jsv json validation datapower 2 Comments 3,238 Views
DataPower firmware 6.0.0.x and 6.0.1.y implement draft-03.
Find a working draft-04 sample in this developerWorks DataPower forum posting (with 126.96.36.199 firmware):
Side-effect of request type JSON is creation of context __JSONASJSONX and conversion of input as JSONX.
188.8.131.52 service export attached to this posting has request type Non-XML and JSON parsing is done by JSONiq xfrom action doing store:///identity-json.xq.
In developerWorks DataPower forum thread Date Conversion from Gregorain to Hijri Asif asked on how to convert Date to Hijri. Wikipedia told me that Hijri is the islamic calendar. External links section showed Calendar Converter link (http://www.fourmilab.ch/documents/calendar/) and that site is pretty cool. It converts date entered in one format to many others (Gregorian, Julian day, Julian, Hebrew, Islamic, Persian, Mayan, Bahá'í, Indian Civil, French Republican, ISO-8601, Unix time(), Excel Serial Day Number).
First lets see both in action, against XSLT and GatewayScript coproc2 endpoints:
The 2nd shows a small difference of GatewayScript to previous JSON processing on DataPower. GatewayScript implements RFC7159 which allows any JSON element at top level, while previous RFC4627 required top level element to be either JSON array or JSON object:
OK, here is stylesheet gregorian_to_islamic.xsl more or less straight translated to XSLT (the needed parts only).
Since the complete work is done in the modules, gregorian_to_islamic.js is minimal:
With the first release (184.108.40.206) GatewayScript will be available there will be no crypto library support.
Anyway, since 220.127.116.11 GatewayScript does not ship any crypto funcitons, using self written or found libraries is your only current option.
Doing "View Page Source" I saw that these 4 code parts were included into the page:
You get them unmodified if you do "Save Page as" as "complete webpage".
So I decided to make 4 modules out of them, store under "local:" on DataPower and just require("aes-ctr") in order to use it. To make functionality available from the module the last line "module.exports = ...;" had to be appended to each file. And in order to use functionality eg. from module "utf8" var Utf8 = require("utf8"); had to be added at the top of the modules.
Here you can see demonstration GatewayScript aes.demo.js in action:
Now we have seen that aes.demo.js works fine, here is it completely:
The little helper function "_()" at the bottom of aes.demo.js was only intended to be a nice oneline implementation of "byte array to hex string" conversion.
(at least it produces the needed hexadecimal output for the NIST test vectors above)
As stated in other postings DataPower JSONiq (extensions to XQuery) implements version 0.4.42 of the spec:
In case you want to play with other 1.0 JSONiq implementation like http://try.zorba.io/ you find the differences post 0.4.42 here:
A "process JSON input sample" was posted here:
And this is JSONiq script groups.xq:
Attached to this developerWorks Forum posting you may find coproc2gatewayscipt.zip service export.
In case you are an "early access program" customer for 18.104.22.168 you may start using coproc2gatewayscript service just now ...
What is the first program that should be shown -- of course "Hello world".
This is the complete GatewayScript Hello_world.js:
$ echo '["foobar"]' | coproc2 Hello_world.js - http://dp2-l3:2227 ; echo
Input array with "foobar" indicates that Hello_world.js does not make use of the input at all.
I just remembered that I created request-headers.xq JSONiq script in this previous blog posting:
It just reads the request headers and outputs an array of small objects with key being HTTP header name, and value being corresponding HTTP header value. This is request-headers.xq:
And this is request-headers.js GatewayScript generating same output similarly:
The output array "arr" gets initialized as empty array.
"for(var h in hs)" just itereates over all headers.
And "arr.push()" allows to extend an array without allocating space first.
Finally "session.output.write(arr);" just outputs the result JSON array for us.
Here you can see it in action:
Output against JSONiq enpoint of coproc2all service looks nicer, but is the same:
Unlike XSLT/XQuery processors GatewayScript does not allow the script to execute be stored in a DataPower context.
coproc2 services all store the script to execute in "xsl" context and use it to transform.
Selection of GatewayScript in WebGUI allows for "local:" and "store:" locations only.
So far, so good -- as we all know we can store a (XML) nodeset in temporary: folder by <dp:dump-nodes> DataPower extension function.
So this is the small difference between old auxiliary stylesheet coproc2.xsl and new coproc2a.xsl:
$ diff coproc2.xsl coproc2a.xsl
And this is the small change needed for GatewayScript endpoint of coproc2 service (use "temporary:///js" instead of "xsl" context):