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
>> 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
>> 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.
>>> 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
>> 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?
>> 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