Chiba

Ronald van Kuijk wrote:
> Hi,
>
> After long debugging and comparing, I'm convinced that ditching the 
> javacode for schema2xform in favour or the one in the wsdl2xforms 
> project is a good thing.
>
> There is one issue, and that is that Chiba dos not like xsi:type or 
> xforms:type attributes on neither instance elements nor binds. Two 
> things can be done. One is that the schema2xforms is adapted to remove 
> these (or not add them), the other is extending (fixing?) Chiba. I'm 
> willing to donate some time for this, so please let me know.
>   

Chiba barfs NullPointerException, when it finds type that it doesn't 
know. Otherwise xsi:type and xforms:type work well enough. I attached a 
patch, that fixes the NullPointerException for unknown types. The patch 
was for Chiba 2.3, so I'm not sure if it works with Chiba 3.

  Tambet

Hahaha.... I did not expect that just preventing the validation would be 
'the right thing to do' but if it comes from you I believe it is :-)... 
I could have done something similar myself if I'd just dared to :-[

I went the other way, preventing your schema2xform.xsl from adding type 
attributes to elements of a complex type which works to. In addition to 
this I'd rather have the xforms:type on the bind then the xsi:type, 
feels like it kind of fits better there, but that is an unimportant detail

Besides this issue, two other small had to be solved before Chiba works 
with custom types. That is adding the custom namespace to the root 
element of the document and also referencing the schema from the model 
schema attribute. If all three are done, your patch is not needed. This 
was because I wanted full schema validation, but your schema2xforms.xsl 
creates more constraints in the form, so schemavalidation is not realy 
needed anymore.

I just got all this fixed (took me 6 hours since my 'xslt' was a bit 
rusty), but if your patch also works (I'll give it a try) there are 2 
solutions. It would mean though that your schema2xforms could also be 
used for previous versions of Chiba.

Btw, I saw you use chiba:match which does not seem to be in the current 
3.0.0 branche. Does this mean schema2xforms is just for 2? Since there 
is code in chiba 2 for this but I'm not sure if that could be ported to 
3.0 since migration to saxon took place.

Nice work btw with the xslt, Only thing missing for me is an extension 
to be able to generate labels/hints/tooltips from external files in 
addition to getting it from annotations.

Ronald

Op 20-07-09 23:05, Tambet Matiisen schreef:
> Ronald van Kuijk wrote:
>> Hi,
>>
>> After long debugging and comparing, I'm convinced that ditching the 
>> javacode for schema2xform in favour or the one in the wsdl2xforms 
>> project is a good thing.
>>
>> There is one issue, and that is that Chiba dos not like xsi:type or 
>> xforms:type attributes on neither instance elements nor binds. Two 
>> things can be done. One is that the schema2xforms is adapted to 
>> remove these (or not add them), the other is extending (fixing?) 
>> Chiba. I'm willing to donate some time for this, so please let me know.
>
> Chiba barfs NullPointerException, when it finds type that it doesn't 
> know. Otherwise xsi:type and xforms:type work well enough. I attached 
> a patch, that fixes the NullPointerException for unknown types. The 
> patch was for Chiba 2.3, so I'm not sure if it works with Chiba 3.
>
>  Tambet

Op 20-07-09 23:05, Tambet Matiisen schreef:
> Ronald van Kuijk wrote:
>> Hi,
>>
>> After long debugging and comparing, I'm convinced that ditching the 
>> javacode for schema2xform in favour or the one in the wsdl2xforms 
>> project is a good thing.
>>
>> There is one issue, and that is that Chiba dos not like xsi:type or 
>> xforms:type attributes on neither instance elements nor binds. Two 
>> things can be done. One is that the schema2xforms is adapted to 
>> remove these (or not add them), the other is extending (fixing?) 
>> Chiba. I'm willing to donate some time for this, so please let me know.
>
> Chiba barfs NullPointerException, when it finds type that it doesn't 
> know. Otherwise xsi:type and xforms:type work well enough. I attached 
> a patch, that fixes the NullPointerException for unknown types. The 
> patch was for Chiba 2.3, so I'm not sure if it works with Chiba 3.
>
>  Tambet
Just tested the patch on 3.0.0 from svn and it works to. I also added 
this check to the xfType just below it... would be nice if Joern/Lars 
could add it to the code (assuming there are no sideeffects, but running 
the testcases should show this quickly.)

Anybody has any idea how to run those btw.. Nothing happening here.

Ronald

Ronald van Kuijk wrote:
> Hahaha.... I did not expect that just preventing the validation would 
> be 'the right thing to do' but if it comes from you I believe it is 
> :-)... I could have done something similar myself if I'd just dared to 
> :-[

Sometimes when deadline is ticking you just do what makes it work ;).

>
> I went the other way, preventing your schema2xform.xsl from adding 
> type attributes to elements of a complex type which works to. In 
> addition to this I'd rather have the xforms:type on the bind then the 
> xsi:type, feels like it kind of fits better there, but that is an 
> unimportant detail

The original purpose of the script was to make XForms forms for SOAP web 
services. SOAP requires xsi:type attribute for all elements. I agree, 
that having them within binds would be nicer.

The correct solution would be, that wsdl2xforms generates xsi:type and 
schema2xforms generates type attribute within bind.

>
> Besides this issue, two other small had to be solved before Chiba 
> works with custom types. That is adding the custom namespace to the 
> root element of the document and also referencing the schema from the 
> model schema attribute. If all three are done, your patch is not 
> needed. This was because I wanted full schema validation, but your 
> schema2xforms.xsl creates more constraints in the form, so 
> schemavalidation is not realy needed anymore.

I considered this approach, because very often WSDL already contains 
schema. But there were several obstacles:
1. Schema in WSDL file is for all services in that file. Copying that 
schema into every form would make all forms unnecessarily big. One 
option here would be to put schema into separate file that is referenced 
from every form.
2. I was bit puzzled, when schema rules will apply. When schema defines 
a type (simple or complex), and you use that type, then everything is 
clear. But when schema defines rules for element with certain name, then 
these rules will be applied only if this element is a root element? But 
I had the elements inside SOAP envelope. So it would require me to 
generate fake schema for SOAP envelope. I finally decided, that 
generating all validation rules with binds would be clearer and easier.

>
> I just got all this fixed (took me 6 hours since my 'xslt' was a bit 
> rusty), but if your patch also works (I'll give it a try) there are 2 
> solutions. It would mean though that your schema2xforms could also be 
> used for previous versions of Chiba.
>
> Btw, I saw you use chiba:match which does not seem to be in the 
> current 3.0.0 branche. Does this mean schema2xforms is just for 2? 
> Since there is code in chiba 2 for this but I'm not sure if that could 
> be ported to 3.0 since migration to saxon took place.

This was just workaround, because Chiba didn't support XPath 2.0 
matches() function. Does Chiba 3 use Saxon? Then it should be easy to 
replace.
http://www.saxonica.com/documentation/functions/intro/fn_matches.html

>
> Nice work btw with the xslt, Only thing missing for me is an extension 
> to be able to generate labels/hints/tooltips from external files in 
> addition to getting it from annotations.

Thanks for encouragement. Regarding your question there are several 
possibilities:
1. You could create "texts" instance in XForms file, which is populated 
from external XML file. Then you could use ref attribute of labels, 
hints and help to get the text from that instance. Something like this:

<xforms:instance id="texts" src="texts.xml"/>

<xforms:input ref="somefield">
  <xforms:label ref="instance('texts')/text[@field='somefield']"/>
</xforms:input>

You could make language of your forms changeable on fly, if you include 
language selector on your form:

<xforms:select1 ref="instance('temp')/language">
  <xforms:label>Language</xforms:label>
  <xforms:item>
    <xforms:value>en</xforms:value>
    <xforms:label>English</xforms:value>
  <xforms:item>
  <xforms:item>
    <xforms:value>et</xforms:value>
    <xforms:label>Estonian</xforms:value>
  <xforms:item>
</xforms:select>

<xforms:input ref="somefield">
  <xforms:label 
ref="instance('texts')/language[@code=instance('temp')/language]/text[@field='somefield']"/>
</xforms:input>

Orbeon Forms Builder does it this way.

2. If you would prefer doing it during generation, then you could use 
document() function of XSLT.
http://www.saxonica.com/documentation/functions/intro/xslt_document.html

In both cases you would have to override few templates at the end of 
schema2xforms.xsl file. Preferable would be to make your own .xsl, which 
imports schema2xforms.xsl.

  Tambet

Op 21-07-09 09:59, Tambet Matiisen schreef:
> Ronald van Kuijk wrote:
>> Hahaha.... I did not expect that just preventing the validation would 
>> be 'the right thing to do' but if it comes from you I believe it is 
>> :-)... I could have done something similar myself if I'd just dared 
>> to :-[
>
> Sometimes when deadline is ticking you just do what makes it work ;).

Yep it certainly (but unfortunately) is. I wonder though how this 
relates to the spec. Might need to readup a little in this area maybe.

>
>>
>> I went the other way, preventing your schema2xform.xsl from adding 
>> type attributes to elements of a complex type which works to. In 
>> addition to this I'd rather have the xforms:type on the bind then the 
>> xsi:type, feels like it kind of fits better there, but that is an 
>> unimportant detail
>
> The original purpose of the script was to make XForms forms for SOAP 
> web services. SOAP requires xsi:type attribute for all elements. I 
> agree, that having them within binds would be nicer.
>
> The correct solution would be, that wsdl2xforms generates xsi:type and 
> schema2xforms generates type attribute within bind.
>

I'll see what I can do. I grasp the internals of the xslt now to some 
extend (still need to read about xslt2.0 stuff like tunnels)

>>
>> Besides this issue, two other small had to be solved before Chiba 
>> works with custom types. That is adding the custom namespace to the 
>> root element of the document and also referencing the schema from the 
>> model schema attribute. If all three are done, your patch is not 
>> needed. This was because I wanted full schema validation, but your 
>> schema2xforms.xsl creates more constraints in the form, so 
>> schemavalidation is not realy needed anymore.
>
> I considered this approach, because very often WSDL already contains 
> schema. But there were several obstacles:
> 1. Schema in WSDL file is for all services in that file. Copying that 
> schema into every form would make all forms unnecessarily big. One 
> option here would be to put schema into separate file that is 
> referenced from every form.
> 2. I was bit puzzled, when schema rules will apply. When schema 
> defines a type (simple or complex), and you use that type, then 
> everything is clear. But when schema defines rules for element with 
> certain name, then these rules will be applied only if this element is 
> a root element?

Afaik not, chiba 3 validates patterns in types for each element at any 
level. No need for patterns in constraints. The thing is that I want as 
little duplication as possible to be able to make changes. That is why I 
also do not like the fact that bind on certain elements in the form do 
not work anymore (like group, repeat). Now if Imove them in my form, I 
have to change the nodeset attribute, whereas with a bind that was not 
needed. Much easier editing for noobs

> But I had the elements inside SOAP envelope. So it would require me to 
> generate fake schema for SOAP envelope. I finally decided, that 
> generating all validation rules with binds would be clearer and easier.
>
Oh, but I'm not talking about internal schemas, I hate those to. No, 
just have a separate xsd and reference that. I'll make this configurable 
as well. in the xslt so
>>
>> I just got all this fixed (took me 6 hours since my 'xslt' was a bit 
>> rusty), but if your patch also works (I'll give it a try) there are 2 
>> solutions. It would mean though that your schema2xforms could also be 
>> used for previous versions of Chiba.
>>
>> Btw, I saw you use chiba:match which does not seem to be in the 
>> current 3.0.0 branche. Does this mean schema2xforms is just for 2? 
>> Since there is code in chiba 2 for this but I'm not sure if that 
>> could be ported to 3.0 since migration to saxon took place.
>
> This was just workaround, because Chiba didn't support XPath 2.0 
> matches() function. Does Chiba 3 use Saxon? Then it should be easy to 
> replace.
> http://www.saxonica.com/documentation/functions/intro/fn_matches.html
>
Yes, 3 uses Saxon. Thanks for the pointer, I knew them but maybe thought 
the chiba:match was there for a specific reason. I'll put that in the 
xslt as well and also make it configurable via a param. Would something 
like 'ChibaCompliancy' as a param with either 2 or 3 as a value do it 
for you? Leaving it out gives you the full form
>>
>> Nice work btw with the xslt, Only thing missing for me is an 
>> extension to be able to generate labels/hints/tooltips from external 
>> files in addition to getting it from annotations.
>
> Thanks for encouragement. Regarding your question there are several 
> possibilities:
>
That is needed from time to time right ;-)

> 2. If you would prefer doing it during generation, then you could use 
> document() function of XSLT.
> http://www.saxonica.com/documentation/functions/intro/xslt_document.html
>
> In both cases you would have to override few templates at the end of 
> schema2xforms.xsl file. Preferable would be to make your own .xsl, 
> which imports schema2xforms.xsl.
>

I certainly want it during generation and I know the xslt document() 
function. Unfortunately, the file is not in xml format and I do not want 
to write a converter for it, So it probably will have to become an xslt 
extension

I'm still working on an xforms designer/editor for Eclipse. Would you 
mind if this xslt is included there so one could right-click on an xsd 
and have an xform generated?

Ronald

Op 21-07-09 09:59, Tambet Matiisen schreef:
>
>> Nice work btw with the xslt, Only thing missing for me is an 
>> extension to be able to generate labels/hints/tooltips from external 
>> files in addition to getting it from annotations.
>
>
I have some more compliments ;-)

The id generation is much more interesting since they often stay the 
same when regenerating and are related to the 'path'. if I now make sure 
I have a .xhtml file which I'm editing and make sure if I regenerate 
from an xsd in a *different file*, there are much less items in the 
'diffs' then with the id generation of the java version. Sure I could 
have changed that, but never took the time. Makes it easy to 'merge' 
small changes. Cool.

Second compliment is that once you get the way the xlst's work it's kind 
of clean and obvious (besides the fact that I do not have read about 
'tunnel' yet there seem to be some nice tricks used...e.g. the tm:schema 
function)

Btw, are you also interested in having optionally generated 'default 
alerts'? And what about tooltips/hints (have not looked if this is 
possible already) and text before/after the elements? All from either 
annotations in the xsd, parent xsd or from an external file.

Ronald

Chiba uses Saxon and does support XPath 2.0

On Tue, Jul 21, 2009 at 11:24 AM, Ronald van Kuijk<rvkuijk@...> wrote:
> Op 21-07-09 09:59, Tambet Matiisen schreef:
>> Ronald van Kuijk wrote:
>>> Hahaha.... I did not expect that just preventing the validation would
>>> be 'the right thing to do' but if it comes from you I believe it is
>>> :-)... I could have done something similar myself if I'd just dared
>>> to :-[
>>
>> Sometimes when deadline is ticking you just do what makes it work ;).
>
> Yep it certainly (but unfortunately) is. I wonder though how this
> relates to the spec. Might need to readup a little in this area maybe.
>
>>
>>>
>>> I went the other way, preventing your schema2xform.xsl from adding
>>> type attributes to elements of a complex type which works to. In
>>> addition to this I'd rather have the xforms:type on the bind then the
>>> xsi:type, feels like it kind of fits better there, but that is an
>>> unimportant detail
>>
>> The original purpose of the script was to make XForms forms for SOAP
>> web services. SOAP requires xsi:type attribute for all elements. I
>> agree, that having them within binds would be nicer.
>>
>> The correct solution would be, that wsdl2xforms generates xsi:type and
>> schema2xforms generates type attribute within bind.
>>
>
> I'll see what I can do. I grasp the internals of the xslt now to some
> extend (still need to read about xslt2.0 stuff like tunnels)
>
>>>
>>> Besides this issue, two other small had to be solved before Chiba
>>> works with custom types. That is adding the custom namespace to the
>>> root element of the document and also referencing the schema from the
>>> model schema attribute. If all three are done, your patch is not
>>> needed. This was because I wanted full schema validation, but your
>>> schema2xforms.xsl creates more constraints in the form, so
>>> schemavalidation is not realy needed anymore.
>>
>> I considered this approach, because very often WSDL already contains
>> schema. But there were several obstacles:
>> 1. Schema in WSDL file is for all services in that file. Copying that
>> schema into every form would make all forms unnecessarily big. One
>> option here would be to put schema into separate file that is
>> referenced from every form.
>> 2. I was bit puzzled, when schema rules will apply. When schema
>> defines a type (simple or complex), and you use that type, then
>> everything is clear. But when schema defines rules for element with
>> certain name, then these rules will be applied only if this element is
>> a root element?
>
> Afaik not, chiba 3 validates patterns in types for each element at any
> level. No need for patterns in constraints. The thing is that I want as
> little duplication as possible to be able to make changes. That is why I
> also do not like the fact that bind on certain elements in the form do
> not work anymore (like group, repeat). Now if Imove them in my form, I
> have to change the nodeset attribute, whereas with a bind that was not
> needed. Much easier editing for noobs
>
>> But I had the elements inside SOAP envelope. So it would require me to
>> generate fake schema for SOAP envelope. I finally decided, that
>> generating all validation rules with binds would be clearer and easier.
>>
> Oh, but I'm not talking about internal schemas, I hate those to. No,
> just have a separate xsd and reference that. I'll make this configurable
> as well. in the xslt so
>>>
>>> I just got all this fixed (took me 6 hours since my 'xslt' was a bit
>>> rusty), but if your patch also works (I'll give it a try) there are 2
>>> solutions. It would mean though that your schema2xforms could also be
>>> used for previous versions of Chiba.
>>>
>>> Btw, I saw you use chiba:match which does not seem to be in the
>>> current 3.0.0 branche. Does this mean schema2xforms is just for 2?
>>> Since there is code in chiba 2 for this but I'm not sure if that
>>> could be ported to 3.0 since migration to saxon took place.
>>
>> This was just workaround, because Chiba didn't support XPath 2.0
>> matches() function. Does Chiba 3 use Saxon? Then it should be easy to
>> replace.
>> http://www.saxonica.com/documentation/functions/intro/fn_matches.html
>>
> Yes, 3 uses Saxon. Thanks for the pointer, I knew them but maybe thought
> the chiba:match was there for a specific reason. I'll put that in the
> xslt as well and also make it configurable via a param. Would something
> like 'ChibaCompliancy' as a param with either 2 or 3 as a value do it
> for you? Leaving it out gives you the full form
>>>
>>> Nice work btw with the xslt, Only thing missing for me is an
>>> extension to be able to generate labels/hints/tooltips from external
>>> files in addition to getting it from annotations.
>>
>> Thanks for encouragement. Regarding your question there are several
>> possibilities:
>>
> That is needed from time to time right ;-)
>
>> 2. If you would prefer doing it during generation, then you could use
>> document() function of XSLT.
>> http://www.saxonica.com/documentation/functions/intro/xslt_document.html
>>
>> In both cases you would have to override few templates at the end of
>> schema2xforms.xsl file. Preferable would be to make your own .xsl,
>> which imports schema2xforms.xsl.
>>
>
> I certainly want it during generation and I know the xslt document()
> function. Unfortunately, the file is not in xml format and I do not want
> to write a converter for it, So it probably will have to become an xslt
> extension
>
> I'm still working on an xforms designer/editor for Eclipse. Would you
> mind if this xslt is included there so one could right-click on an xsd
> and have an xform generated?
>
> Ronald
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Chiba-devel mailing list
> Chiba-devel@...
> https://lists.sourceforge.net/lists/listinfo/chiba-devel
>

I already tried replacing chiba:match with fn:matches and that works 
perfectly in contraints with patterns.

Op 21-07-09 14:48, Joern Turner schreef:
> Chiba uses Saxon and does support XPath 2.0
>
> On Tue, Jul 21, 2009 at 11:24 AM, Ronald van Kuijk<rvkuijk@...>  wrote:
>    
>> Op 21-07-09 09:59, Tambet Matiisen schreef:
>>      
>>> Ronald van Kuijk wrote:
>>>        
>>>> Hahaha.... I did not expect that just preventing the validation would
>>>> be 'the right thing to do' but if it comes from you I believe it is
>>>> :-)... I could have done something similar myself if I'd just dared
>>>> to :-[
>>>>          
>>> Sometimes when deadline is ticking you just do what makes it work ;).
>>>        
>> Yep it certainly (but unfortunately) is. I wonder though how this
>> relates to the spec. Might need to readup a little in this area maybe.
>>
>>      
>>>> I went the other way, preventing your schema2xform.xsl from adding
>>>> type attributes to elements of a complex type which works to. In
>>>> addition to this I'd rather have the xforms:type on the bind then the
>>>> xsi:type, feels like it kind of fits better there, but that is an
>>>> unimportant detail
>>>>          
>>> The original purpose of the script was to make XForms forms for SOAP
>>> web services. SOAP requires xsi:type attribute for all elements. I
>>> agree, that having them within binds would be nicer.
>>>
>>> The correct solution would be, that wsdl2xforms generates xsi:type and
>>> schema2xforms generates type attribute within bind.
>>>
>>>        
>> I'll see what I can do. I grasp the internals of the xslt now to some
>> extend (still need to read about xslt2.0 stuff like tunnels)
>>
>>      
>>>> Besides this issue, two other small had to be solved before Chiba
>>>> works with custom types. That is adding the custom namespace to the
>>>> root element of the document and also referencing the schema from the
>>>> model schema attribute. If all three are done, your patch is not
>>>> needed. This was because I wanted full schema validation, but your
>>>> schema2xforms.xsl creates more constraints in the form, so
>>>> schemavalidation is not realy needed anymore.
>>>>          
>>> I considered this approach, because very often WSDL already contains
>>> schema. But there were several obstacles:
>>> 1. Schema in WSDL file is for all services in that file. Copying that
>>> schema into every form would make all forms unnecessarily big. One
>>> option here would be to put schema into separate file that is
>>> referenced from every form.
>>> 2. I was bit puzzled, when schema rules will apply. When schema
>>> defines a type (simple or complex), and you use that type, then
>>> everything is clear. But when schema defines rules for element with
>>> certain name, then these rules will be applied only if this element is
>>> a root element?
>>>        
>> Afaik not, chiba 3 validates patterns in types for each element at any
>> level. No need for patterns in constraints. The thing is that I want as
>> little duplication as possible to be able to make changes. That is why I
>> also do not like the fact that bind on certain elements in the form do
>> not work anymore (like group, repeat). Now if Imove them in my form, I
>> have to change the nodeset attribute, whereas with a bind that was not
>> needed. Much easier editing for noobs
>>
>>      
>>> But I had the elements inside SOAP envelope. So it would require me to
>>> generate fake schema for SOAP envelope. I finally decided, that
>>> generating all validation rules with binds would be clearer and easier.
>>>
>>>        
>> Oh, but I'm not talking about internal schemas, I hate those to. No,
>> just have a separate xsd and reference that. I'll make this configurable
>> as well. in the xslt so
>>      
>>>> I just got all this fixed (took me 6 hours since my 'xslt' was a bit
>>>> rusty), but if your patch also works (I'll give it a try) there are 2
>>>> solutions. It would mean though that your schema2xforms could also be
>>>> used for previous versions of Chiba.
>>>>
>>>> Btw, I saw you use chiba:match which does not seem to be in the
>>>> current 3.0.0 branche. Does this mean schema2xforms is just for 2?
>>>> Since there is code in chiba 2 for this but I'm not sure if that
>>>> could be ported to 3.0 since migration to saxon took place.
>>>>          
>>> This was just workaround, because Chiba didn't support XPath 2.0
>>> matches() function. Does Chiba 3 use Saxon? Then it should be easy to
>>> replace.
>>> http://www.saxonica.com/documentation/functions/intro/fn_matches.html
>>>
>>>        
>> Yes, 3 uses Saxon. Thanks for the pointer, I knew them but maybe thought
>> the chiba:match was there for a specific reason. I'll put that in the
>> xslt as well and also make it configurable via a param. Would something
>> like 'ChibaCompliancy' as a param with either 2 or 3 as a value do it
>> for you? Leaving it out gives you the full form
>>      
>>>> Nice work btw with the xslt, Only thing missing for me is an
>>>> extension to be able to generate labels/hints/tooltips from external
>>>> files in addition to getting it from annotations.
>>>>          
>>> Thanks for encouragement. Regarding your question there are several
>>> possibilities:
>>>
>>>        
>> That is needed from time to time right ;-)
>>
>>      
>>> 2. If you would prefer doing it during generation, then you could use
>>> document() function of XSLT.
>>> http://www.saxonica.com/documentation/functions/intro/xslt_document.html
>>>
>>> In both cases you would have to override few templates at the end of
>>> schema2xforms.xsl file. Preferable would be to make your own .xsl,
>>> which imports schema2xforms.xsl.
>>>
>>>        
>> I certainly want it during generation and I know the xslt document()
>> function. Unfortunately, the file is not in xml format and I do not want
>> to write a converter for it, So it probably will have to become an xslt
>> extension
>>
>> I'm still working on an xforms designer/editor for Eclipse. Would you
>> mind if this xslt is included there so one could right-click on an xsd
>> and have an xform generated?
>>
>> Ronald
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge
>> This is your chance to win up to $100,000 in prizes! For a limited time,
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> Chiba-devel mailing list
>> Chiba-devel@...
>> https://lists.sourceforge.net/lists/listinfo/chiba-devel
>>
>>

Op 21-07-09 15:01, Adam Flinton schreef:
>
>> In both cases you would have to override few templates at the end of
>> schema2xforms.xsl file. Preferable would be to make your own .xsl, which
>> imports schema2xforms.xsl.
>>
>
> Where do I get this:
>
> schema2xforms.xsl
>
> ?
>
> Is it the one in the chiba svn?

No, the latest  is in svn on wsdl2xforms in sourceforge

> In both cases you would have to override few templates at the end of
> schema2xforms.xsl file. Preferable would be to make your own .xsl, which
> imports schema2xforms.xsl.
>

Where do I get this:

schema2xforms.xsl

?

Is it the one in the chiba svn?

Adam

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSI recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere
For more information and to find out how you can switch, visit http://www.connectingforhealth.nhs.uk/nhsmail

********************************************************************************************************************

Ronald van Kuijk wrote:
> Op 21-07-09 15:01, Adam Flinton schreef:
>
>>> In both cases you would have to override few templates at the end of
>>> schema2xforms.xsl file. Preferable would be to make your own .xsl, which
>>> imports schema2xforms.xsl.
>>>
>>>
>> Where do I get this:
>>
>> schema2xforms.xsl
>>
>> ?
>>
>> Is it the one in the chiba svn?
>>
>
> No, the latest  is in svn on wsdl2xforms in sourceforge
>
>
Thanks

Adam

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSI recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere
For more information and to find out how you can switch, visit http://www.connectingforhealth.nhs.uk/nhsmail

********************************************************************************************************************

Hi Adam,

this isn't maintained in the Chiba Project any more (ours was just
some barebones) - please refer to the WSDL2XForms project on
sourceforge:
http://sourceforge.net/projects/wsdl2xforms

On Tue, Jul 21, 2009 at 3:01 PM, Adam Flinton<adam.flinton@...> wrote:
>
>> In both cases you would have to override few templates at the end of
>> schema2xforms.xsl file. Preferable would be to make your own .xsl, which
>> imports schema2xforms.xsl.
>>
>
> Where do I get this:
>
> schema2xforms.xsl
>
> ?
>
> Is it the one in the chiba svn?
>
> Adam
>
> ********************************************************************************************************************
>
> This message may contain confidential information. If you are not the intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSI recipients
> NHSmail provides an email address for your career in the NHS and can be accessed anywhere
> For more information and to find out how you can switch, visit http://www.connectingforhealth.nhs.uk/nhsmail
>
> ********************************************************************************************************************
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Chiba-devel mailing list
> Chiba-devel@...
> https://lists.sourceforge.net/lists/listinfo/chiba-devel
>