Passing parameters in a recursive procedure

Hi Martin,

 

I've just started to play with o:xml and I love it already...

 

I have a question related to the fact that parameters are passed by reference.

 

The following procedure is recursive : it converts a decimal number into another base (lower than 10 in that simple example).

 

I cannot think of a way to keep the value of the $number parameter after the recursive call :

 

<o:procedure name='base_p'>
  <o:param name='number' type='Number'/>
  <o:param name='base' type='Number' select='2'/>
  <o:do>
   <o:choose>
    <o:when test='$number+1>$base'>
     <base_p number='($number - ($number mod $base)) div $base' base='$base'/>
     <o:eval select='$number mod $base'/>  <!-- Here, the value of $number has changed -->

    </o:when>
    <o:otherwise><o:eval select='$number'/></o:otherwise>
   </o:choose>
  </o:do>
 </o:procedure>
 Result : <base_p number='12938' base='8'/> <!-- The result is not the one expected -->

 

The following is basically the same procedure, where the parameter is not changed. But the result is "reversed", which is not quite satisfactory

<o:procedure name='base_p2'>
  <o:param name='number' type='Number'/>
  <o:param name='base' type='Number' select='2'/>
  <o:do>
   <o:choose>
    <o:when test='$number+1>$base'>
     <o:eval select='$number mod $base'/> <!-- Here, the value of $number has not changed yet -->

     <base_p2 number='($number - ($number mod $base)) div $base' base='$base'/>
    </o:when>
    <o:otherwise><o:eval select='$number'/></o:otherwise>
   </o:choose>
  </o:do>
 </o:procedure>
 Result : <base_p2 number='12938' base='8'/> <!-- Expected result, to be read from the right to the left... -->

 

I tried to deep-copy the parameter, to no effect : the value is changed after the recursive call, as can be expected. 

 

My question : can I declare the parameter in such a way that its value is kept after a call to a function that will use the same parameter name, which is obviously the case of a recursive call ?

 

This is the same routine as a function which works as expected, the parameters being evaluated before the call to the function.

 

<o:function name='base_f'>
  <o:param name='number' type='Number'/>
  <o:param name='base' type='Number' select='2'/>
  <o:do>
   <o:choose>
    <o:when test='$number+1>$base'>
     <o:return select='concat(base_f(($number - ($number mod $base)) div $base,$base),($number mod $base).string())'/>
    </o:when>
    <o:otherwise><o:return select='$number.string()'/></o:otherwise>
   </o:choose>
  </o:do>
 </o:function>
 Result : <o:eval select='base_f(12938,8)'/> <!-- Expected value -->

 

_______________________________________________
o-xml mailing list
o-xml@...
http://lists.pingdynasty.com/mailman/listinfo/o-xml

Re: Passing parameters in a recursive procedure

On 3 Oct 2004, at 20:12, Christophe Chenon wrote:

> I've just started to play with o:xml and I love it already...

that's so nice!

>  I have a question related to the fact that parameters are passed by 
> reference.

I think what you're seeing is quite simply a bug.
Parameters are passed by ref as you say, but the value types (String, 
Number, Boolean) are immutable - any operations on them produce new 
values rather than change the object state.
The current interpretor uses a simple stack mechanism whereby the 
variables currently in scope are 'hidden' when a function call is made. 
It should be done the same way for procedure calls. Instead it seems 
the recursive procedure call sets the same 'number' variable that is 
already being used.

I'm currently doing some deep compiler refactoring for the next 
version, I'll fit in a fix for this. If you can, pls report the problem 
on bugzilla:
http://bugz.pingdynasty.com

thanks Christophe, speak more soon!

/m

Displaying HTML code pulled from a database

Martin,

We were discussing the other day about reading/writing HTML code to  
databases. Well I just tested reading HTML inputed from a form,  
processed with o-xml and writing it to a database.

This is what I input:

  A story with a <a href="www.dirtyeye.com">link</a> to my website.  
Wonder If it works.

This is what gets stored in the DB:

+---------+---------------------+-----------+------------------------- 
+----------------------------------------------------------------------- 
----------------+
| item_id | pub_date            | posted_by | title                   |  
story                                                                    
               |
+---------+---------------------+-----------+------------------------- 
+----------------------------------------------------------------------- 
----------------+
|       8 | 2004-10-03 10:40:48 |         3 | A new story             |  
A story with a <a href="www.dirtyeye.com">link</a> to my website.  
Wonder If it works.
+---------+---------------------+-----------+------------------------- 
+----------------------------------------------------------------------- 
----------------+
8 rows in set (0.00 sec)

When I read the data back from the database I get this as the HTML  
output:

<p>A story with a &lt;a href="www.dirtyeye.com"&gt;link&lt;/a&gt; to my  
website. Wonder If it works.</p>

Is there anyway to output the proper HTML?

Also apart from  db:quote() are there any other functions that I can  
use in the DB extension to format input?

Thanks,
Glen

Re: Displaying HTML code pulled from a database

On 3 Oct 2004, at 22:51, Glen Barnes wrote:

> Is there anyway to output the proper HTML?

The angle brackets are escaped when the string data is output as XML.
What you can do is parse the string data (using the Java extensions 
parse() function) and output the parse results:

<o:eval select="java:parse($stringdata)"
	   xmlns:java="http://www.o-xml.com/java/"/>

This gets a bit tedious when you have to iterate over rows of results. 
You might find you can do it with a single XPath replace() expression.

It would be better if instead you could specify the data type in the 
result template directly, or if full expressions were allowed. Maybe in 
the next version!

> Also apart from  db:quote() are there any other functions that I can 
> use in the DB extension to format input?

You can use any function or expression as normal, but there currently 
aren't any others defined in the db namespace specifically. What input 
formatting do you need?

hth,

/m

Re: Displaying HTML code pulled from a database

On 5 Oct 2004, at 10:13, Martin Klang wrote:

>
> On 4 Oct 2004, at 23:36, Glen Barnes wrote:
>
>>> This gets a bit tedious when you have to iterate over rows of 
>>> results. You might find you can do it with a single XPath replace() 
>>> expression.
>>
>> Isn't replace() an Xpath 2.0 function?
>
> yes sorry, I meant o:Path replace()!
> as in
> $results/column/text().replace(java:parse($results/column/text()))
>

Right-O then...It works. Anywhere that I pull marked-up content from a 
DB I can use the parse function to convert it to the correct format. 
Then in my template I simply use an xsl:copy-of to output a deep copy 
of the variable and it will work. I just tested it and all is OK.

/b

ObjectBox 1.1.0

Hi all,

Long time no release!

A new version of the o:XML compiler is due. It constitutes quite a 
large rewrite of the core types and the compiler/interpreter 
infrastructure.
It fixes a number of problems with how the o:XML type implementations 
interface with the Java engine. Now all Node calls can be overloaded by 
derived types. This means that you can overload 'system' functions like 
string(), boolean() etc to specialise the behaviour of certain types.

The refactored compiler also brings o:XML closer to the objective of 
native code generation and target-language independence.  Firstly the 
core types are now all generated from o:XML templates in a way that can 
be repurposed for generating Java from o:XML. Secondly the expression 
parser has been updated to produce MLML output, as an intermediary step 
in this transformation process.

In terms of new features, notably there's support for passing session 
information to o:XML programs on the command line and within a Servlet 
environment. By declaring an o:session program parameter, a Map 
containing session variables will be supplied. This makes it quite easy 
to develop stateful web applications. Example ->
<o:program>
    <o:param name="o:session" type="Map"/>
    <!-- get, set, check, remove session attributes with $o:session -->
</o:program>

The error reporting is greatly improved, and stack traces show what 
o:XML function calls in what source files lead up to the error.

The release also includes refactored and updated database extensions: 
it is now possible to use full expressions within SQL and result 
templates.

Online documentation will be updated in the next few days to reflect 
the changes.

A pre-release version is available for download now, here:
http://download.pingdynasty.com/o-xml/ObjectBox/ObjectBox-1.1.0rc1/

If you find any problems or bugs please report them to 
http://bugz.pingdynasty.com/ or to this list.

have fun!

/m

Request for help

Hello all,

I've got no less than three requests to make, so if you're looking for 
something to fill those long winter days/nights with look no further 
(for those of you having summer now: go surf!)

Firstly, a lot could be done to improve the inline documentation of the 
core types and the o:Lib library types. It would be particularly good 
to have more examples available for the library code.
Also the XSLT stylesheets used to generate the documentation could be 
refined.
The docs are generated from source files to DocBook format and then 
HTML, and come out looking like this:
http://www.o-xml.org/docs/lib/io/File.html
(A little) more information about o:XML inline documentation is 
available here: http://www.o-xml.org/projects/document.html

Secondly, both the compiler/interpreter and the library code of o:XML 
uses extensive unit tests to ensure bug-less builds and releases. 
However the tests aren't complete and a lot of the functionality needs 
further tests. If you could see yourself writing tests for either o:XML 
core types and functions, o:Path expressions or o:Lib then all help 
would be greatly appreciated!

If documentation and writing tests don't tickle your fancy there's a 
nice juicy bit of coding for someone to sink their teeth into ---
Neither of the SAX or DOM interfaces provide enough information to 
properly drive the o:XML compilation process. Instead of the current 
DOM-based solution I would like to implement a Xerces-based XNI 
compiler. XNI provides data about file encodings and source locations 
which DOM falls short on, and internal DTD which I don't think SAX 
does. If anyone is interested in lending a hand or leading the 
development of this component pls contact me. The work involves coding 
an XNI event handler that builds up a hierarchy of ObjectBox Template 
objects. More info on XNI (Xerces Native Interface) is here: 
http://xml.apache.org/xerces2-j/xni.html
Also do let me know if you know of other alternatives to DOM/SAX that 
might be suitable (must provide enough information about the source 
document to produce a /near/identical result, plus source file 
line/column info).
Another, smaller, Java-job is to write a SAX adaptor for the output - 
so far I've not seen any signs of demand for this though.

Also, of course, if anyone wants to contribute o:Lib library code, work 
on improving the compiler/interpretor, or help out in any other way let 
me know - all help is welcome and much appreciated!

/m

interface changes - naming convention

Me again - with a request for opinions!

The interfaces of the core types of o:XML as well as the library code 
have so far been designed to be short-and-sweet. This however has lead 
to potentially confusing situations such as:
Element.attribute(Name name): get an attribute
Element.attribute(Name name, Node value): set an attribute
Now if you add another function that sets an attribute, that takes 
simply an Attribute node, then things get worse:
Element.attribute(Attribute value): set an attribute

A slightly more verbose, arguably less pretty, definitely less 
confusing alternative would be to use Java-style getters and setters:
Element.getAttribute(Name name): get an attribute
Element.setAttribute(Attribute value): set an attribute

Camel-casing may have its own drawbacks - getAValue() for example looks 
pretty weird, and setHTTPURL() vs setHttpUrl() seems a loose/loose. 
Still these special cases are less commonly occurring than the whole 
get/set confusion. Also note that o:XML already uses camel-casing for 
certain functions such as String.substringBefore().

One could argue that since o:XML uses XPath extensively, we should 
adopt the XPath/XSLT naming convention of all lower-case, hyphenated 
names. That would get us:
Element.get-attribute(Name name): get an attribute
Element.set-attribute(Attribute value): set an attribute
get-a-value()
set-http-url()
String.substring-before(String str): just like XPath

etc.

There are naming standards for example for Java, and XML Schema, that 
could be leveraged. In the case of Java it is supposed to be camel-case 
with all-uppercase acronyms, and a lower-case first character for 
methods and upper-case for classes, but this isn't followed to the 
letter, so to speak, eg java.net.HttpURLConnection is irregular.

I would ideally like to align all interfaces for the 1.1.0 release, 
rather than postpone the inevitable, so it is essential to get your 
feedback asap - reply now! The discussion could / should be extended to 
Type as well as function names, and what to do about those XPath 
functions.

regards, looking forward to your comments,

/m

code generation with UML/XMI and o:xml ?

_______________________________________________
o-xml mailing list
o-xml@...
http://lists.pingdynasty.com/mailman/listinfo/o-xml

Re: code generation with UML/XMI and o:xml ?

John,

I've attached updated stylesheets that produce o:XML stubs from XMI 1.0 
(ArgoUML) and XMI 1.2 (Poseidon) respectively.
There's also a stylesheet for reverse-engineering the model - it takes 
an o:XML source file and produces an XMI model. So far only in XMI 1.2 
format, but should be easy enough to port to 1.0.

Together the xslt's provide simple UML round-trip engineering for o:XML.
Admittedly the stylesheets are very simple and don't handle all aspects 
of a model - so far only Package, Class, Generalization, Operation and 
Attribute constructs are mapped.

In ArgoUML the save file (model.zargo) is a Zip archive containing the 
XMI model description. Unzip the file and run the 1.0 xsl to generate 
o:XML source code.
In Poseidon, you can export a model as XMI or grab it from the save 
file (model.zuml) as with ArgoUML. Main difference is that the Posedion 
XMI format is v1.2 and includes diagram information as well as model 
data.

For reverse-engineering, generate an XMI file from o:XML sources with 
the oml-to-xmi stylesheet, and simply open the resulting XMI file in 
Poseidon. You won't see a diagram, but the model is there. If you 
right-click on a package you can then choose 'Create class diagram from 
package' which will add all types to a new class diagram. Or create the 
diagram you want, and then add the classes.

When I've a bit of time I'll publish the stylesheets on the website, 
together with some sample models (the core o:XML types and o:Lib comes 
to mind).

I'd be very interested to hear how you get on with this, and from 
anyone using different modelling software. XMI is becoming a commonly 
accepted format for UML, albeit in many different dialects. It would be 
nice to test the stylesheets and some generated models against a few 
different products.

regards,

/m

On 16 Oct 2004, at 23:17, John Cobo wrote:

> Martin,
>  
> Thank you for the prompt response.  My interest comes from two 
> directions.
> 1. My job includes a bit of UML to specify systems in a big IT 
> department.  In big organisations there is often a chasm between 
> analysts and developers.  UML is meant to give them a common language, 
> but I have always felt that UML diagrams would be 100 times more 
> useful if one could generate something from them.  Even a basic 
> generated prototype would help ensure the UML is complete, accurate, 
> and reflects what the analyst and business are talking about.  It 
> seems that o:xml would be a great tool for such things from what I 
> have read (and you have written) about it.  I also have a personal 
> system up my sleeve I would like to develop, but am too lazy to code 
> anything more than once.
>  
> 2. My second reason for interest is that I have done a bit of work 
> with MDA tools.  While they are useful, I think they would be MUCH 
> more useful if they allowed for model to model transformations.  There 
> is talk of this as a theory, but I have yet to see it.  Wouldn't it be 
> great if you could drop in one class with stereotype <user 
> authentication> (for example).  Save the model to xmi, run a program 
> that would expand that one class into several following a pattern.  
> These would then be in the updated/generated XMI model ready for 
> configuration to the specific business problem at hand.  Eventual code 
> generation to JAVA or whatever could be a lot simpler if most of the 
> work was done in model to model generation(s) ant therefore able to be 
> edited in the model itself rather than in transformations to code 
> which is therefore not in the model for next time.
>  
>  
> The short answer is, yes, I have XMI, I generally use the latest 
> community version of Poseidon.  I'm not sure which XMI version that 
> produces and I am at the wrong PC now to check.
>  
> If you don't mind sharing the XSLT you mentioned I would enjoy (??) 
> having a look.  I am not sure I have fully got my head around o:xml 
> yet, but did manage basic XSLT.
>  
> Thanks,
>  
> John Cobo
>

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
o-xml mailing list
o-xml@...
http://lists.pingdynasty.com/mailman/listinfo/o-xml