xsltforms-support — XSLTForms support list

[Xsltforms-support] XSLTForms and REST

[Stephen C. <Ste...@ut...>]

Hello All,

I have been reading up on REST, there is quite a bit more to it than I first imagined.

Its essential to be able to read and set header information in the client, such as to read the "Location" header in a POST response to extract a newly generated resource id.

I'm wondering if anyone has looked at this in respect of XSLTForms?

Cheers

Steve Cameron

Re: [Xsltforms-support] format-number()

[<fr...@fl...>]

Hi Alain,

First of all, sorry for not have changed the subject line, I pressed  
'send' too quick.

In my Invoice form I need to represent (calculated) amounts with 2  
digits after the decimal point or comma. (Round(100*X) div 100)  
doesn't work as it suppresses trailing zeros and sometimes produces  
unwanted decimals. I can think of a fairly complex formula,  
manipulating each amount as a string, but that is very cumbersome.

So yes, a function to format numbers would come handy.

Thanks!

Fred




Citeren COUTHURES Alain <ala...@ag...>:

> Hello Fred,
>
>> Short question: has the format-number() function been implemented?
>
> This can be an useful extension. It is not implemented because
> format-number() is not an XPath function but an XSLT function
> potentially referencing xsl:decimal-format elements.
>
> Would you need an xsl:decimal-format element?
>
> Thanks!
>
> -Alain

Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

[COUTHURES A. <ala...@ag...>]

Le 05/01/2011 12:22, Stephen Cameron a écrit :
> You should used xf:output/@value instead of xf:output/@ref for 
> rendering XPath expressions which are not also node sets. There is no 
> error message about that but there should be one.
>
> Oh, is this saying render the node value, as opposed to render the 
> value of the first node in the nodeset?
>
<xf:output value="instance('get_airport')/@startPosition + 
instance('grid1')/pos + position() - 2" /> is correct because this is 
not a node but a calculation.
>
> Unfortunate but if that's the only way forward for you then so be it. 
>  Possibly worth going along that path for a while to see what happens, 
> maybe if some people thing no more will come for you for free they 
> will put their hands in their pocket to help continue it as fully 
> open-source. Personally I think the current XSLTForms version is 
> capable of making money for people.
>
If people are able to make money with XSLTForms, they can certainly 
consider to sell it with their solutions.
>
>
> XPath 2.0 partial support can help: in this test case, the "to" 
> operator could be used.
>
> I can't see how or find an example, surely not  "node[x to y ]"?
>
> Maybe something like "node[member-of-set(position(),x to y)]"?
>
Have a look at 
http://www.w3.org/TR/2010/REC-xpath-functions-20101214/#func-to
>
>
> There are also possibilities in adding useful extensions. You can 
> already try this experimental extension: add 
> xf:instance/@readonly="true" to each instance with a static content 
> and it will not be validated at loading time. For your test case, the 
> loading time is divided by 2!
>
> WOW! This test really rocks now in FF and shows the client-side XForms 
> engine advantage in full glory.
>
> Not only loading time but moving between pages is faster as well, in 
> fact as fast as what I'd hoped for, marvelous J
>
I expect an even more significant improvement with the commercial version!

Thanks!

-Alain

Re: [Xsltforms-support] format-number()

[COUTHURES A. <ala...@ag...>]

Hello Fred,

> Short question: has the format-number() function been implemented?

This can be an useful extension. It is not implemented because 
format-number() is not an XPath function but an XSLT function 
potentially referencing xsl:decimal-format elements.

Would you need an xsl:decimal-format element?

Thanks!

-Alain

Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

[<fr...@fl...>]

Alain,

Best wishes for 2011!
Short question: has the format-number() function been implemented?

Thanks,

Fred

Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

[Stephen C. <Ste...@ut...>]

Fantastic Alain, Thanks!

See comments below


From: COUTHURES Alain [mailto:ala...@ag...]
Sent: Wednesday, 5 January 2011 7:23 PM
To: Stephen Cameron
Cc: xsl...@li...
Subject: Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

Hello Steve,


Specifically the position() XPath function does not work inside an xf:repeat in FF v3.6 but does work in IE  v8.0, thus you see an incrementing row-number in the first column of the table in the later but not in the former.
In fact, IE is the wrong one! You should used xf:output/@value instead of xf:output/@ref for rendering XPath expressions which are not also node sets. There is no error message about that but there should be one.

Oh, is this saying render the node value, as opposed to render the value of the first node in the nodeset?

Also, as you can see there is still a major difference in the relative performance between IE and FF in this 'paging' table demo using dataisland branch. Viewing the F1 Xpath evaluation times its clear that  the Xpath for the repeat 'page' nodeset is by far the longest time (>2500 ms in IE). I tried rewriting this XPath to see if I could improve this time but without any success.

Its pretty clear why this should be expensive as its actually testing each of the 1000 gml:featureMember nodes to see if they match the predicate, as follows:

instance('airport')/gml:featureMember[position()>=instance('grid1')/pos and position()<instance('grid1')/pos+instance('grid1')/stride]/*

However, changing this to the following (which is not quite correct logically but potentially better) doesn't improve the time at all:

instance('airport')/gml:featureMember[position()=instance('grid1')/pos]/following-sibling::*[position()<=instance('grid1')/stride]/*

The logically correct path would be:

instance('airport')/gml:featureMember[position()=instance('grid1')/pos]/self::* | following-sibling::*[position()<instance('grid1')/stride]/*

I tried looking at the generated XPath 'XXXExpr' functions, to understand why this might be the case, but so far without any insights.
I'm now designing a commercial version of XSLTForms for performance issues. This implies as many changes such as the ones done for the dataisland branch, first, but will allow to change the general behavior of XSLTForms consisting now in looking at everything if there is something to be done or not.
Unfortunate but if that's the only way forward for you then so be it.  Possibly worth going along that path for a while to see what happens, maybe if some people thing no more will come for you for free they will put their hands in their pocket to help continue it as fully open-source. Personally I think the current XSLTForms version is capable of making money for people.

XPath 2.0 partial support can help: in this test case, the "to" operator could be used.
I can't see how or find an example, surely not  "node[x to y ]"?
Maybe something like "node[member-of-set(position(),x to y)]"?

There are also possibilities in adding useful extensions. You can already try this experimental extension: add xf:instance/@readonly="true" to each instance with a static content and it will not be validated at loading time. For your test case, the loading time is divided by 2!
WOW! This test really rocks now in FF and shows the client-side XForms engine advantage in full glory.

Not only loading time but moving between pages is faster as well, in fact as fast as what I'd hoped for, marvelous :)


Unfortunately, a commercial version requires also to work on obfuscating XSLT+JS and on restricting use on a registered domain name.



A lot of work implies a lot of time and any kind of support is welcome!

Best wishes for 2011

-Alain

Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

[COUTHURES A. <ala...@ag...>]

Hello Steve,

> Specifically the position() XPath function does not work inside an 
> xf:repeat in FF v3.6 but does work in IE  v8.0, thus you see an 
> incrementing row-number in the first column of the table in the later 
> but not in the former.
>
In fact, IE is the wrong one! You should used xf:output/@value instead 
of xf:output/@ref for rendering XPath expressions which are not also 
node sets. There is no error message about that but there should be one.
>
> Also, as you can see there is still a major difference in the relative 
> performance between IE and FF in this 'paging' table demo using 
> dataisland branch. Viewing the F1 Xpath evaluation times its clear 
> that  the Xpath for the repeat 'page' nodeset is by far the longest 
> time (>2500 ms in IE). I tried rewriting this XPath to see if I could 
> improve this time but without any success.
>
> Its pretty clear why this should be expensive as its actually testing 
> each of the 1000 gml:featureMember nodes to see if they match the 
> predicate, as follows:
>
> instance('airport')/gml:featureMember[position()>=instance('grid1')/pos 
> and position()<instance('grid1')/pos+instance('grid1')/stride]/*
>
> However, changing this to the following (which is not quite correct 
> logically but potentially better) doesn't improve the time at all:
>
> instance('airport')/gml:featureMember[position()=instance('grid1')/pos]/following-sibling::*[position()<=instance('grid1')/stride]/*
>
> The logically correct path would be:
>
> instance('airport')/gml:featureMember[position()=instance('grid1')/pos]/self::* 
> | following-sibling::*[position()<instance('grid1')/stride]/*
>
> I tried looking at the generated XPath 'XXXExpr' functions, to 
> understand why this might be the case, but so far without any insights.
>
I'm now designing a commercial version of XSLTForms for performance 
issues. This implies as many changes such as the ones done for the 
dataisland branch, first, but will allow to change the general behavior 
of XSLTForms consisting now in looking at everything if there is 
something to be done or not.

XPath 2.0 partial support can help: in this test case, the "to" operator 
could be used.

There are also possibilities in adding useful extensions. You can 
already try this experimental extension: add 
xf:instance/@readonly="true" to each instance with a static content and 
it will not be validated at loading time. For your test case, the 
loading time is divided by 2!

Unfortunately, a commercial version requires also to work on obfuscating 
XSLT+JS and on restricting use on a registered domain name.

A lot of work implies a lot of time and any kind of support is welcome!

Best wishes for 2011

-Alain

[Xsltforms-support] XForms course in Rockville, Maryland, 14-15 February 2011

[C. M. Sperberg-M. <cm...@bl...>]

Readers of this list are presumably not much in need of XForms
training, so the announcement below may not apply to you.  But
if you know people who ARE in need to XForms training, please
forward the relevant information to them -- especially if they are in
the Washington, DC, area.

It may be worth noting, as a point of interest, that the course will
be taught using XSLTForms.  (Thanks, Alain!)

* * * * * * * * * *

Black Mesa Technologies is pleased to announce a two-day hands-on
introductory course on XForms to take place 14-15 February 2011 in
Rockville, Maryland, in the training facilities of Mulberry
Technologies.


INTRODUCTION TO XFORMS FOR XML USERS

   Rockville, Maryland
   14-15 February 2011

   http://www.blackmesatech.com/2011/02/XForms/

This two-day hands-on course introduces XForms as a technology for
building special-purposes XML editors with limited functionality and
correspondingly simple user interfaces. XForms is built on the model /
view / controller idiom, in which the ‘model’ is a set of XML
documents, the ‘view’ is specified using XHTML and XForms widgets, and
the ‘controller’ takes the form of declarative links between widgets
and elements or attributes in the XML documents. With XForms, projects
can develop vocabulary- and task-specific editors which require less
training and provide better task-specific support than full XML
editors; it is thus easier to allow domain experts to examine and
modify XML encoding, and routine tasks can be performed more quickly
and reliably.

TOPICS

Topics include:

  - design goals of XForms
  - the XForms processing model and the model / view / controller idiom
  - padded-cell editors
  - XForms widgets
  - datatypes in XForms
  - auto-calculating values
  - validation in the client
  - customized error messages
  - conditional display of parts of the form
  - multiple instance documents
  - dynamic user interfaces
  - using auxiliary documents to make multi-lingual interfaces
  - tabbed interfaces for multi-part forms
  - step-by-step wizard-style interfaces
  - variable repetitions of an element
  - repetitions among unlike elements
  - deployment issues and interaction with the HTTP server
  - where to go from here

During the class, students will develop a small XForms application
with a multi-part interface, multiple widget types, and the ability to
add, modify, and delete records in a set. Students will be encouraged
to take their class exercise files with them so that they can continue
to work with them after the class. Prerequisites

Participants should be comfortable editing XML documents and have some
knowledge of HTML markup. Familiarity with XPath is desirable but not
required. Programming experience is not required. Students may bring
their own laptops or may use a classroom machine.

LOGISTICS

When and where

This course will be held Monday and Tuesday, 14-15 February 2011, at

   Mulberry Technologies, Inc.
   17 West Jefferson St., Suite 207
   Rockville, MD 20850

Thanks to Mulberry Technologies for hosting the course.

For other logistical information, see 

    http://www.blackmesatech.com/2011/02/XForms


REGISTRATION / INFO

To reserve a space, to register, or to ask for more information,
please send email to in...@bl... or call us at
505/747-4224.



-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

[Xsltforms-support] FW: [deegree-users] FW: deegree 3 postgis datastore config example

[Stephen C. <Ste...@ut...>]

Oops, didn't actually mean for this to cc to xsltforms, sorry

-----Original Message-----
From: Stephen Cameron [mailto:Ste...@ut...]
Sent: Tuesday, 4 January 2011 1:54 PM
To: dee...@li...
Cc: xsl...@li...
Subject: Re: [Xsltforms-support] [deegree-users] FW: deegree 3 postgis datastore config example

Hi Markus,

Thanks for your detailed reply.

A few quick thoughts:
(1) Regarding Netkernel, I am very interested in the concepts behind it but have no first hand experience. At present I am coming to grips with the whole REST paradigm (read 'REST in Practice' (http://oreilly.com/catalog/9780596805838) over Christmas, which was very insightful). Perhaps a top level of XML caching (in CLOB) might be a useful optional feature to consider, falling through to lower levels based on specific request type/content. Netkernel might offer an easy way to try this out, but probably something for later.
(2) Definitely ease of configuration is a major requirement to make deegree WFS software more widely appreciated, so simple configuration "by convention" at the simplest (beginner) level seems good.
(3) "I think the way to go is a custom format for GML-version agnostic definition of feature types and relational mapping" -> Still not sure I agree about this, but I'll do some reading and make a separate list.
(4) Perhaps auto-generation of a default WFS-T client web-interface based on server feature configuration (whatever it might be) would be a nice feature :)
(5) I'll make what I have done with Xforms for WFS-T generation scripts available, no point in waiting.

-----Original Message-----
From: Markus Schneider [mailto:sch...@la...]
Sent: Saturday, 1 January 2011 2:09 AM
To: dee...@li...
Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config example

Hi Stephen,

I am sending this to the list, as it may be of interest to Just (and
others) as well.

Am 30.12.2010 10:57, schrieb Stephen Cameron:
> I thought I'd put a few thoughts down in response to the previous comments that you sent to me (below). Understanding my thinking and what I have done to date might be helpful in regards to deegree 3 design (and I need to document my work anyway :) ).
>
> The first thing to say is that I think that the "hybrid" approach that you are taking makes a lot of sense. The caching of features in a XML format is highly desirable for performance reasons obviously [in regard to caching, if you haven't already take a look at the NetKernal product (http://www.1060research.com/netkernel/) that I came across recently, it has XML caching as a fundamental aspect of its design].

Exactly. One of the main benefits is reconstruction speed. If combined
with a relational decomposition, the BLOB becomes a kind of cache.
Thanks for the link. Do you think deegree 3 could still benefit from it?
The actual serialization / deserialization is pretty much solved  and we
have to use our own feature model internally...

> I guess the real issue is how this caching integrates with the filtered searching, in an XML database the raw XML is indexed so this is simple, but I imagine it is not so simple if you want to offer a hybrid XML&  relational capability. [I don't see this subject as being in my field of expertise at all. but intuition makes me wonder at the possibility of using xlinks as a kind of reference within the server itself to integrate the two parts].

I considered using the XML datatypes (e.g. in PostGreSQL or Oracle).
However, there are some downsides:

- No evaluation of spatial predicates.
- Evaluation of XPath-expressions that cross feature boundaries (from a
feature to a referenced feature) is not possible.
- Using a BLOB allows to use alternative encodings (e.g. Binary XML,
GZipped XML, ...). PostGIS always uses CLOB for XML.
- In some use-cases, relational decomposition is still what one wants.
This is not handled by the XML datatype.

All this is possible if one combines BLOB-mode with a traditional
relational decomposition. The downside is that it's more complicated
than just using the XML datatype and introduces redundancy. Note that
relational mapping could also be partial, i.e. if you just require
database filtering for specific properties of a feature type, it should
be possible to just define tables/columns for these.

>
> To focus on my current interests, I see WFS-T from the perspective of a 'generic scientific data management tool' and want to leverage the deegree software infrastructure for this purpose. The primary considerations, in order of descending priority, in this respect are:
>
>          1. Server response is XML format, allowing complex data relationships to be modeled.
>          2. Server response (XML) can be readily transformed for presentation purposes using XSLT.
>          3. Create, Read, Update, Delete (CRUD) transaction capable with a well defined and understandable syntax.
>          4. Filtering and searching capability, allowing you to deal effectively with large sets of data.
>          5. Spatially aware as server supports GML and spatial operations.
>
> The first 4 capabilities above can be utilised in a browser based client, in particular via the use of a web standard designed for handling and manipulating XML, namely XForms. This is the task I set myself early this year, to demonstrate that WFS-T could be used with XForms in this way. [The 5th aspect is also handled by some web-apps (e.g. OpenLayers) but not in an nicely integrated way with 1-4 as yet].
>
> It may be of interest to you to know that the genesis of this idea was my previous interest in XPath as a powerful and widely applicable declarative programming language, (which lead me to an interest in things like Apache Cocoon and JXPath) before starting my current job.
>
> In my current job I initially developed a web-client with a lot of custom Javascript code for doing filtered WFS-T GetFeature requests. After this was done I was asked to add the CRUD capability, on finding the XSLTForms project and with my prior XPath interests I decided to have a go at doing everything with XForms (which uses XPath) and hopefully to even replace my initial custom Javascript with an XForms based filtered search solution.
>
> The key advantage of XSLTForms is not so much that it can make use of XSLT support in the browser, but that it is a cross-browser, non-plugin solution. So, the user doesn't have to do anything special to make it work and you get a nice Ajax kind of web-app, due to the lack of page refreshes. However, XSLTForms is still very Javascript dependant, the XSLT transformation aspect in the name 'XSLTForms' is to translate the XForm XML files into Javascript and XHTML via an stylesheet instruction in the XForm XML. I have found this approach works fine in Firefox, Chrome and Safari. It is too slow in IE8, but it should be fine in IE9.
>
> Another motivating factor in this second version of my web-client was the idea that you can, using XML technologies, go a long way towards the grand goal of 'schema generated forms'. This is a simple concept that once you have designed a schema you can then use that as the model for generating data forms. I don't think there are too many web-application frameworks that don't allow you to do generate entity classes from a relational db schema, and web forms as well but usually very crude and no filtered search support.
>
> So to summarize my basic ideas and approach, (1) I wanted to make use of XForms for the client and to put any minimal 'business logic' required into the forms themselves, (2) Make use of the capabilities of the deegree WFS (items 1-5 above) on the server side and without any further custom server-side code. (3) Model the data in a schema document and generate the required XForms for CRUD, with filtered 'read' capability, from that schema.
>
> In regard to the last item, I have used a relational database schema (in XML format, for the sake of convenience more than anything else as my db design tool 'ERMapper' uses XML as its raw data file format) as the schema from which to generate the XForms and also to generate the deegree feature-configuration annotated XML Schema file. I had in mind from the start to swap this over to make use of the deegree feature-configuration file as the primary data model (XForms can use XML Schema files for data model validation by the way) but initially thought this was too complex to tackle, also I wanted to wait for deegree 3 release to see what this provided.
>
> The schema generated XForms aspect of this work has taken considerably more time than I anticipated but (thanks to some late hours and some understanding from my boss of the wider application of what I have been doing) it is now at a useful stage. I still have some work to do on the filtered search aspect but a working proof-of-concept is in place for that final part. All of this will be released under an GNU Library General Public License soon but my present thinking is that there is no value in doing this until WFS V2.0 support is available in deegree 3.0, with the view that this resolves a couple of issues that I have encountered in providing a complete set of CRUD functionality (mainly the code lists and update issues)
>
> So whilst in the short-term I am having to look to an alternative, more conventional, approach due to time constraints, I do think that what I have done to date with XForms and WFS-T has great potential. I'm not alone in this thinking, as its seems to me I am following a branch (or parallel) to the so-called XRX architecture. In my case XForms is common and REST and XQuery are replaced by WFS-T and OGC Filter Encoding Specification (it wouldn't surprise me to see REST and XQuery come into WFS spec though :) ).
>
> In conclusion then, my main interest is to see how the schema generated forms approach can work best with deegree 3. If the annotated schema is to be dropped in favour of FeatureStore configuration files, I wonder if this is going away from my philosophy of having a single point-of-truth schema (of one or other format) and generating (almost) everything else off that schema. Presently, I don't know how a FeatureStore configuration integrates with the DescribeFeatureType response, are these maintained independently? I think that what you write about annotated schemas being "bloated, complicated and offer many ways to express the same structure" is only true if you are trying to create them without the aid a schema editor. I feel that using a tool (built with XForms perhaps??) avoids these problems to a significant extent, after all XML was designed mainly as a machine-to-machine message format.

In deegree 3, GML application schemas are still very important (this is
the way the MemoryFeatureStore / PostGISFeatureStore BLOB mode) learns
about the feature type hierarchy. And as GML application schemas are
becoming more and more important, this representation will also be of
primary interest in the future.

However, for some use cases, I don't consider GML application schemas to
be the best way to encode feature types. Problems:

- A GML application schemas is always dependent on a GML-version.
However, if one just wants to map a single PostGIS table, one usually
doesn't care about that. It should be sufficient to specify the table to
be able to query it via WFS in any GML version (2 / 3.0 / 3.1 / 3.2 /
...). This is already possible in deegree 3 and works well [1]. For
DescribeFeatureType responses, the schema is generated on-the-fly (for
the requested GML version). For GetFeature / GetGmlObject requests, the
GML is exported for the requested version as well.
- Writing a correct GML application schema is complex. I think it's much
more approachable to think about feature types and properties instead of
having to deal with GML core schemas, substitution groups, complex
types, simple types and element declarations. One goal for the
PostGISFeatureStore config is to make simple things as simple as
possible, but support everything that's possible in GML schema. For
schemas that use "custom property" declarations (which can virtually be
anything that's possible in XML schema), the original schemas could be
an option for augmenting the configuration (otherwise, one would end up
redefining XML schema).
- Of course it's not only about defining the feature types, but also
about relational mapping. Besides being GML-version dependent and
complicated, the annotation approach in deegree 2 has the additional
downside that it cannot be validated.

I think the way to go is a custom format for GML-version agnostic
definition of feature types and relational mapping. If an application
produces GML application schemas, there's always the possibility to
derive the configuration automatically.

>
> If any aspect of what I have described above is of interest in relation to deegree 3 design or functionality I am keen to help further with this. In regard to XSLTForms in particular, if you have any specific interest in this, I know the developer Alain Couthures (in France) is very keen to find demo use-cases and collaborators.

I also consider XSLTForms an interesting approach, as it has a very
clean separation of client and server layers. However, at the moment, I
don't have a use-case for it. If it pops up, I will let you guys know.

>
> As a final question, do you know of any other standard that provides the same kind of generic functionality as WFS? It seems to me that in providing a standard to deal with spatial data interoperability the OGC (and implementers such as yourselves) have addressed general problems and so produced software of much wider application. REST (as I'm currently reading) seems close but does not have the level of application to data as does WFS-T, any others?

Hmm. Not really...

Best regards and a happy new year,
Markus

[1]
http://wiki.deegree.org/deegreeWiki/deegree3/WorkspaceConfiguration/FeatureStoreConfiguration#PostGISexamples

>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Markus Schneider [mailto:sch...@la...]
> Sent: Thursday, 23 December 2010 8:27 PM
> To: Stephen Cameron
> Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config example
>
> Hi Stephen,
>
> Am 23.12.2010 um 03:06 schrieb Stephen Cameron:
>
>> Hi Markus,
>>
>> On reflection I am now committed to a relational database solution, I need to finalize my project by the end of January, so very regretfully, in the short-term at least, I will have to look to replacing my WFS-T+XForms with another
>> non-WFS based forms alternative.
>
> That's sad to hear. Staying with deegree 2 WFS is not an alternative for now?
>
>>
>> This was the last thing I wish to do, as inevitably this means Java entity beans and an ORM mapping/persistence layer all of which is just not needed (IMHO) if you just want to move data between a database and XML (grrr!).
>>
>> After all the work I have put into this it's quite difficult to have to do switch course, but in the longer term perhaps for the best. I am very keen to contribute to the deegree 3.1 relational mapping work if I can, and getting rid of the current stress will be good. I'm sure my work with XForms will find a good use once WFS 2.0 is available.
>
> What is the special thing about WFS 2.0 that will change? I am currently not really aware of a change in the transaction behaviour between 1.1.0 and 2.0.0...
>
>>
>> Just thinking the mapping last night I pictured a compilation process of an annotated schema (similar to compilation of JSPs) with some properties ('pseudo-XML-nodes') of the compiled product being (or wrapping) JDBC prepared statements. To make this work reliably I think there could be a validation method where the database schema is tested by the compiled XML schema in terms of column names, datatypes and other assumptions using the JDBC database metadata access.
>>
>> The need to generate an ORM mapping layer is only necessary for applying business logic, which for a pure data management system is not needed. In my view, thinking in the XML ways is much more productive, such as by attaching event listeners to parser events.
>>
>> No doubt you have some good ideas as to how you want to go forward with this as well.
>
>  From my view (and for the use-cases we have in mind), the "hybrid" approach seems to be most desirable, i.e. combining BLOB mode with a (full or partial) object-relational decomposition. This would combine all benefits:
>
> - Fast reconstruction of features (from the BLOB), no need for subsequent SELECTs
> - Evaluation of arbitrary filters on the database
> - Possibility to access/alter the decomposed feature by third-party applications or plain SQL. If combined with triggers, an alteration of a property could also force a deletion of the BLOB, so the FeatureStore knows that it has to reconstruct the feature from the relational decomposition - afterwards it would recreate the BLOB.
>
> For the configuration of the relational mapping, I would rather see the use of the FeatureStore configuration files than annotated schemas, as schemas have two downsides:
>
> - They are bloated, complicated and offer many ways to express the same structure (e.g. choices vs. substitution groups)
> - They are GML version dependent
>
> Have a good Christmas as well.
>
> Best regards,
> Markus
>
>>
>> Have a good Christmas.
>>
>>
>>
>> -----Original Message-----
>> From: Markus Schneider [mailto:sch...@la...]
>> Sent: Wednesday, 22 December 2010 3:39 AM
>> To: dee...@li...
>> Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config example
>>
>> Hi Stephen,
>>
>> Am 21.12.2010 13:05, schrieb Stephen Cameron:
>>
>>> What is possible in BLOB mode as far as wfs:Update transactions go, can you update both simple and complex properties? As my web client is only interested in direct or XSLT transformed WFS GetFeature responses I might be able to go forward with that and maybe swap back to Relational later on. But it does seem to me like BLOB mode ( a.k.a. XML database :) ) is the future anyway.
>>
>> Actually, I am a bit unsure what works and what doesn't :-) We only tested with updates on primitive values / geometries so far.
>>
>> Would be very interesting to hear about your experiences so we can see what is still missing.
>>
>> A good starting point for setting up a complex application schema with deegree 3 would be deegree inspireNode [1]. It should be pretty easy to set up. The step-by-step guide (and a look at the configuration files) should be enough to give you an idea how it works. Afterwards, just adapt it to your schema and re-start with a clean PostGIS database.
>>
>> Best regards,
>> Markus
>>
>> [1] http://wiki.deegree.org/deegreeWiki/InspireNode
>>
>>>
>>> Thanks
>>>
>>> Steve Cameron
>>>
>>> -----Original Message-----
>>> From: Markus Schneider [mailto:sch...@la...]
>>> Sent: Tuesday, 21 December 2010 10:18 PM
>>> To: dee...@li...
>>> Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config
>>> example
>>>
>>> Hi Stephen,
>>>
>>> configuration examples for the PostGISFeatureStore can be found here [1].
>>>
>>>
>>> However, I am afraid that you have to hold your breath a little longer :-( In deegree 3.0, only BLOB mode and relational mapping for *simple feature types* is ready (GeometryProperty / SimpleProperty elements).
>>> The config options you stumbled upon (CodeProperty, CustomMapping, ...) only work partially and were until now only used to test some ideas on complex relational mapping configuration.
>>>
>>> We hope to make progress on the complex relational mapping in January, so it should become available in 3.1 (February) [2].
>>>
>>> If you're interested, I can sent the deegree 3 configuration for the Philosopher example to the list, once I find the time to start working on that again, so we can discuss some ideas.
>>>
>>> Best regards,
>>> Markus
>>>
>>> [1]
>>> http://wiki.deegree.org/deegreeWiki/deegree3/WorkspaceConfiguration/Fe
>>> atureStoreConfiguration#PostGISfeaturestores
>>> [2] http://wiki.deegree.org/deegreeWiki/deegree3/Roadmap
>>>
>>> Am 21.12.2010 11:59, schrieb Stephen Cameron:
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I just looked at the xml schema for the deegree 3 postgis datastore config.
>>>>
>>>>
>>>>
>>>> Is there possibly a simple 'demo' example of an actual config file
>>>> (akin to the old philosophers example)?
>>>>
>>>>
>>>>
>>>> At first glance it looks very interesting, I am keen to try to use it!
>>>>
>>>>
>>>>
>>>> Particularly this bit  looks like something I have been asking for J
>>>>
>>>>
>>>>
>>>>   <!-- === Code property declaration / mapping === -->
>>>>
>>>>   <element name="CodeProperty"
>>>> substitutionGroup="postgisfs:AbstractProperty">
>>>>
>>>>     <complexType>
>>>>
>>>>       <annotation>
>>>>
>>>>         <documentation>Definition of a code-valued property of a
>>>> feature type.</documentation>
>>>>
>>>>         <appinfo>
>>>>
>>>>           <jaxb:class name="CodePropertyDecl"/>
>>>>
>>>>         </appinfo>
>>>>
>>>>       </annotation>
>>>>
>>>>       <complexContent>
>>>>
>>>>         <extension base="postgisfs:AbstractPropertyType">
>>>>
>>>>           <attribute name="codeSpaceMapping" type="string"
>>>> use="optional">
>>>>
>>>>             <annotation>
>>>>
>>>>               <documentation>Mapping expression for the codeSpace
>>>> attribute.</documentation>
>>>>
>>>>             </annotation>
>>>>
>>>>           </attribute>
>>>>
>>>>         </extension>
>>>>
>>>>       </complexContent>
>>>>
>>>>     </complexType>
>>>>
>>>>   </element>
>>>>
>>>>
>>>>
>>>> Also the mapping elements based on the following, how does this work??
>>>>
>>>>
>>>>
>>>>   <element name="AbstractCustomMapping" abstract="true"
>>>> type="postgisfs:AbstractCustomMappingType"/>
>>>>
>>>>   <complexType name="AbstractCustomMappingType">
>>>>
>>>>     <annotation>
>>>>
>>>>       <documentation>Defines the mapping for (a part of) a custom
>>>> property.</documentation>
>>>>
>>>>       <appinfo>
>>>>
>>>>         <jaxb:class name="CustomMapping"/>
>>>>
>>>>       </appinfo>
>>>>
>>>>     </annotation>
>>>>
>>>>     <attribute name="path" type="string" use="required">
>>>>
>>>>       <annotation>
>>>>
>>>>         <documentation>(Relative) XPath targeted by this
>>>> mapping.</documentation>
>>>>
>>>>       </annotation>
>>>>
>>>>     </attribute>
>>>>
>>>>     <attribute name="mapping" type="string">
>>>>
>>>>       <annotation>
>>>>
>>>>         <documentation>Mapping expression.</documentation>
>>>>
>>>>       </annotation>
>>>>
>>>>     </attribute>
>>>>
>>>>   </complexType>
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> Steve Cameron
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> -
>>>> --------
>>>> Lotusphere 2011
>>>> Register now for Lotusphere 2011 and learn how to connect the dots,
>>>> take your collaborative environment to the next level, and enter the
>>>> era of Social Business.
>>>> http://p.sf.net/sfu/lotusphere-d2d
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> deegree-users mailing list
>>>> dee...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/deegree-users
>>>
>>>
>>> --
>>> l a t / l o n  GmbH
>>> Aennchenstrasse 19                 53177 Bonn, Germany
>>> phone ++49 +228 18496-0            fax ++49 +228 18496-29
>>> http://www.lat-lon.de              http://www.deegree.org
>>> Follow deegree on Twitter: http://twitter.com/deegree_org
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> Lotusphere 2011
>>> Register now for Lotusphere 2011 and learn how to connect the dots,
>>> take your collaborative environment to the next level, and enter the
>>> era of Social Business.
>>> http://p.sf.net/sfu/lotusphere-d2d
>>> _______________________________________________
>>> deegree-users mailing list
>>> dee...@li...
>>> https://lists.sourceforge.net/lists/listinfo/deegree-users
>>
>>
>> --
>> l a t / l o n  GmbH
>> Aennchenstrasse 19                 53177 Bonn, Germany
>> phone ++49 +228 18496-0            fax ++49 +228 18496-29
>> http://www.lat-lon.de              http://www.deegree.org
>> Follow deegree on Twitter: http://twitter.com/deegree_org
>>
>


------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
deegree-users mailing list
dee...@li...
https://lists.sourceforge.net/lists/listinfo/deegree-users

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] [deegree-users] FW: deegree 3 postgis datastore config example

[Stephen C. <Ste...@ut...>]

Hi Markus,

Thanks for your detailed reply.

A few quick thoughts:
(1) Regarding Netkernel, I am very interested in the concepts behind it but have no first hand experience. At present I am coming to grips with the whole REST paradigm (read 'REST in Practice' (http://oreilly.com/catalog/9780596805838) over Christmas, which was very insightful). Perhaps a top level of XML caching (in CLOB) might be a useful optional feature to consider, falling through to lower levels based on specific request type/content. Netkernel might offer an easy way to try this out, but probably something for later.
(2) Definitely ease of configuration is a major requirement to make deegree WFS software more widely appreciated, so simple configuration "by convention" at the simplest (beginner) level seems good.
(3) "I think the way to go is a custom format for GML-version agnostic definition of feature types and relational mapping" -> Still not sure I agree about this, but I'll do some reading and make a separate list.
(4) Perhaps auto-generation of a default WFS-T client web-interface based on server feature configuration (whatever it might be) would be a nice feature :)
(5) I'll make what I have done with Xforms for WFS-T generation scripts available, no point in waiting.

-----Original Message-----
From: Markus Schneider [mailto:sch...@la...]
Sent: Saturday, 1 January 2011 2:09 AM
To: dee...@li...
Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config example

Hi Stephen,

I am sending this to the list, as it may be of interest to Just (and
others) as well.

Am 30.12.2010 10:57, schrieb Stephen Cameron:
> I thought I'd put a few thoughts down in response to the previous comments that you sent to me (below). Understanding my thinking and what I have done to date might be helpful in regards to deegree 3 design (and I need to document my work anyway :) ).
>
> The first thing to say is that I think that the "hybrid" approach that you are taking makes a lot of sense. The caching of features in a XML format is highly desirable for performance reasons obviously [in regard to caching, if you haven't already take a look at the NetKernal product (http://www.1060research.com/netkernel/) that I came across recently, it has XML caching as a fundamental aspect of its design].

Exactly. One of the main benefits is reconstruction speed. If combined
with a relational decomposition, the BLOB becomes a kind of cache.
Thanks for the link. Do you think deegree 3 could still benefit from it?
The actual serialization / deserialization is pretty much solved  and we
have to use our own feature model internally...

> I guess the real issue is how this caching integrates with the filtered searching, in an XML database the raw XML is indexed so this is simple, but I imagine it is not so simple if you want to offer a hybrid XML&  relational capability. [I don't see this subject as being in my field of expertise at all. but intuition makes me wonder at the possibility of using xlinks as a kind of reference within the server itself to integrate the two parts].

I considered using the XML datatypes (e.g. in PostGreSQL or Oracle).
However, there are some downsides:

- No evaluation of spatial predicates.
- Evaluation of XPath-expressions that cross feature boundaries (from a
feature to a referenced feature) is not possible.
- Using a BLOB allows to use alternative encodings (e.g. Binary XML,
GZipped XML, ...). PostGIS always uses CLOB for XML.
- In some use-cases, relational decomposition is still what one wants.
This is not handled by the XML datatype.

All this is possible if one combines BLOB-mode with a traditional
relational decomposition. The downside is that it's more complicated
than just using the XML datatype and introduces redundancy. Note that
relational mapping could also be partial, i.e. if you just require
database filtering for specific properties of a feature type, it should
be possible to just define tables/columns for these.

>
> To focus on my current interests, I see WFS-T from the perspective of a 'generic scientific data management tool' and want to leverage the deegree software infrastructure for this purpose. The primary considerations, in order of descending priority, in this respect are:
>
>          1. Server response is XML format, allowing complex data relationships to be modeled.
>          2. Server response (XML) can be readily transformed for presentation purposes using XSLT.
>          3. Create, Read, Update, Delete (CRUD) transaction capable with a well defined and understandable syntax.
>          4. Filtering and searching capability, allowing you to deal effectively with large sets of data.
>          5. Spatially aware as server supports GML and spatial operations.
>
> The first 4 capabilities above can be utilised in a browser based client, in particular via the use of a web standard designed for handling and manipulating XML, namely XForms. This is the task I set myself early this year, to demonstrate that WFS-T could be used with XForms in this way. [The 5th aspect is also handled by some web-apps (e.g. OpenLayers) but not in an nicely integrated way with 1-4 as yet].
>
> It may be of interest to you to know that the genesis of this idea was my previous interest in XPath as a powerful and widely applicable declarative programming language, (which lead me to an interest in things like Apache Cocoon and JXPath) before starting my current job.
>
> In my current job I initially developed a web-client with a lot of custom Javascript code for doing filtered WFS-T GetFeature requests. After this was done I was asked to add the CRUD capability, on finding the XSLTForms project and with my prior XPath interests I decided to have a go at doing everything with XForms (which uses XPath) and hopefully to even replace my initial custom Javascript with an XForms based filtered search solution.
>
> The key advantage of XSLTForms is not so much that it can make use of XSLT support in the browser, but that it is a cross-browser, non-plugin solution. So, the user doesn't have to do anything special to make it work and you get a nice Ajax kind of web-app, due to the lack of page refreshes. However, XSLTForms is still very Javascript dependant, the XSLT transformation aspect in the name 'XSLTForms' is to translate the XForm XML files into Javascript and XHTML via an stylesheet instruction in the XForm XML. I have found this approach works fine in Firefox, Chrome and Safari. It is too slow in IE8, but it should be fine in IE9.
>
> Another motivating factor in this second version of my web-client was the idea that you can, using XML technologies, go a long way towards the grand goal of 'schema generated forms'. This is a simple concept that once you have designed a schema you can then use that as the model for generating data forms. I don't think there are too many web-application frameworks that don't allow you to do generate entity classes from a relational db schema, and web forms as well but usually very crude and no filtered search support.
>
> So to summarize my basic ideas and approach, (1) I wanted to make use of XForms for the client and to put any minimal 'business logic' required into the forms themselves, (2) Make use of the capabilities of the deegree WFS (items 1-5 above) on the server side and without any further custom server-side code. (3) Model the data in a schema document and generate the required XForms for CRUD, with filtered 'read' capability, from that schema.
>
> In regard to the last item, I have used a relational database schema (in XML format, for the sake of convenience more than anything else as my db design tool 'ERMapper' uses XML as its raw data file format) as the schema from which to generate the XForms and also to generate the deegree feature-configuration annotated XML Schema file. I had in mind from the start to swap this over to make use of the deegree feature-configuration file as the primary data model (XForms can use XML Schema files for data model validation by the way) but initially thought this was too complex to tackle, also I wanted to wait for deegree 3 release to see what this provided.
>
> The schema generated XForms aspect of this work has taken considerably more time than I anticipated but (thanks to some late hours and some understanding from my boss of the wider application of what I have been doing) it is now at a useful stage. I still have some work to do on the filtered search aspect but a working proof-of-concept is in place for that final part. All of this will be released under an GNU Library General Public License soon but my present thinking is that there is no value in doing this until WFS V2.0 support is available in deegree 3.0, with the view that this resolves a couple of issues that I have encountered in providing a complete set of CRUD functionality (mainly the code lists and update issues)
>
> So whilst in the short-term I am having to look to an alternative, more conventional, approach due to time constraints, I do think that what I have done to date with XForms and WFS-T has great potential. I'm not alone in this thinking, as its seems to me I am following a branch (or parallel) to the so-called XRX architecture. In my case XForms is common and REST and XQuery are replaced by WFS-T and OGC Filter Encoding Specification (it wouldn't surprise me to see REST and XQuery come into WFS spec though :) ).
>
> In conclusion then, my main interest is to see how the schema generated forms approach can work best with deegree 3. If the annotated schema is to be dropped in favour of FeatureStore configuration files, I wonder if this is going away from my philosophy of having a single point-of-truth schema (of one or other format) and generating (almost) everything else off that schema. Presently, I don't know how a FeatureStore configuration integrates with the DescribeFeatureType response, are these maintained independently? I think that what you write about annotated schemas being "bloated, complicated and offer many ways to express the same structure" is only true if you are trying to create them without the aid a schema editor. I feel that using a tool (built with XForms perhaps??) avoids these problems to a significant extent, after all XML was designed mainly as a machine-to-machine message format.

In deegree 3, GML application schemas are still very important (this is
the way the MemoryFeatureStore / PostGISFeatureStore BLOB mode) learns
about the feature type hierarchy. And as GML application schemas are
becoming more and more important, this representation will also be of
primary interest in the future.

However, for some use cases, I don't consider GML application schemas to
be the best way to encode feature types. Problems:

- A GML application schemas is always dependent on a GML-version.
However, if one just wants to map a single PostGIS table, one usually
doesn't care about that. It should be sufficient to specify the table to
be able to query it via WFS in any GML version (2 / 3.0 / 3.1 / 3.2 /
...). This is already possible in deegree 3 and works well [1]. For
DescribeFeatureType responses, the schema is generated on-the-fly (for
the requested GML version). For GetFeature / GetGmlObject requests, the
GML is exported for the requested version as well.
- Writing a correct GML application schema is complex. I think it's much
more approachable to think about feature types and properties instead of
having to deal with GML core schemas, substitution groups, complex
types, simple types and element declarations. One goal for the
PostGISFeatureStore config is to make simple things as simple as
possible, but support everything that's possible in GML schema. For
schemas that use "custom property" declarations (which can virtually be
anything that's possible in XML schema), the original schemas could be
an option for augmenting the configuration (otherwise, one would end up
redefining XML schema).
- Of course it's not only about defining the feature types, but also
about relational mapping. Besides being GML-version dependent and
complicated, the annotation approach in deegree 2 has the additional
downside that it cannot be validated.

I think the way to go is a custom format for GML-version agnostic
definition of feature types and relational mapping. If an application
produces GML application schemas, there's always the possibility to
derive the configuration automatically.

>
> If any aspect of what I have described above is of interest in relation to deegree 3 design or functionality I am keen to help further with this. In regard to XSLTForms in particular, if you have any specific interest in this, I know the developer Alain Couthures (in France) is very keen to find demo use-cases and collaborators.

I also consider XSLTForms an interesting approach, as it has a very
clean separation of client and server layers. However, at the moment, I
don't have a use-case for it. If it pops up, I will let you guys know.

>
> As a final question, do you know of any other standard that provides the same kind of generic functionality as WFS? It seems to me that in providing a standard to deal with spatial data interoperability the OGC (and implementers such as yourselves) have addressed general problems and so produced software of much wider application. REST (as I'm currently reading) seems close but does not have the level of application to data as does WFS-T, any others?

Hmm. Not really...

Best regards and a happy new year,
Markus

[1]
http://wiki.deegree.org/deegreeWiki/deegree3/WorkspaceConfiguration/FeatureStoreConfiguration#PostGISexamples

>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Markus Schneider [mailto:sch...@la...]
> Sent: Thursday, 23 December 2010 8:27 PM
> To: Stephen Cameron
> Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config example
>
> Hi Stephen,
>
> Am 23.12.2010 um 03:06 schrieb Stephen Cameron:
>
>> Hi Markus,
>>
>> On reflection I am now committed to a relational database solution, I need to finalize my project by the end of January, so very regretfully, in the short-term at least, I will have to look to replacing my WFS-T+XForms with another
>> non-WFS based forms alternative.
>
> That's sad to hear. Staying with deegree 2 WFS is not an alternative for now?
>
>>
>> This was the last thing I wish to do, as inevitably this means Java entity beans and an ORM mapping/persistence layer all of which is just not needed (IMHO) if you just want to move data between a database and XML (grrr!).
>>
>> After all the work I have put into this it's quite difficult to have to do switch course, but in the longer term perhaps for the best. I am very keen to contribute to the deegree 3.1 relational mapping work if I can, and getting rid of the current stress will be good. I'm sure my work with XForms will find a good use once WFS 2.0 is available.
>
> What is the special thing about WFS 2.0 that will change? I am currently not really aware of a change in the transaction behaviour between 1.1.0 and 2.0.0...
>
>>
>> Just thinking the mapping last night I pictured a compilation process of an annotated schema (similar to compilation of JSPs) with some properties ('pseudo-XML-nodes') of the compiled product being (or wrapping) JDBC prepared statements. To make this work reliably I think there could be a validation method where the database schema is tested by the compiled XML schema in terms of column names, datatypes and other assumptions using the JDBC database metadata access.
>>
>> The need to generate an ORM mapping layer is only necessary for applying business logic, which for a pure data management system is not needed. In my view, thinking in the XML ways is much more productive, such as by attaching event listeners to parser events.
>>
>> No doubt you have some good ideas as to how you want to go forward with this as well.
>
>  From my view (and for the use-cases we have in mind), the "hybrid" approach seems to be most desirable, i.e. combining BLOB mode with a (full or partial) object-relational decomposition. This would combine all benefits:
>
> - Fast reconstruction of features (from the BLOB), no need for subsequent SELECTs
> - Evaluation of arbitrary filters on the database
> - Possibility to access/alter the decomposed feature by third-party applications or plain SQL. If combined with triggers, an alteration of a property could also force a deletion of the BLOB, so the FeatureStore knows that it has to reconstruct the feature from the relational decomposition - afterwards it would recreate the BLOB.
>
> For the configuration of the relational mapping, I would rather see the use of the FeatureStore configuration files than annotated schemas, as schemas have two downsides:
>
> - They are bloated, complicated and offer many ways to express the same structure (e.g. choices vs. substitution groups)
> - They are GML version dependent
>
> Have a good Christmas as well.
>
> Best regards,
> Markus
>
>>
>> Have a good Christmas.
>>
>>
>>
>> -----Original Message-----
>> From: Markus Schneider [mailto:sch...@la...]
>> Sent: Wednesday, 22 December 2010 3:39 AM
>> To: dee...@li...
>> Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config example
>>
>> Hi Stephen,
>>
>> Am 21.12.2010 13:05, schrieb Stephen Cameron:
>>
>>> What is possible in BLOB mode as far as wfs:Update transactions go, can you update both simple and complex properties? As my web client is only interested in direct or XSLT transformed WFS GetFeature responses I might be able to go forward with that and maybe swap back to Relational later on. But it does seem to me like BLOB mode ( a.k.a. XML database :) ) is the future anyway.
>>
>> Actually, I am a bit unsure what works and what doesn't :-) We only tested with updates on primitive values / geometries so far.
>>
>> Would be very interesting to hear about your experiences so we can see what is still missing.
>>
>> A good starting point for setting up a complex application schema with deegree 3 would be deegree inspireNode [1]. It should be pretty easy to set up. The step-by-step guide (and a look at the configuration files) should be enough to give you an idea how it works. Afterwards, just adapt it to your schema and re-start with a clean PostGIS database.
>>
>> Best regards,
>> Markus
>>
>> [1] http://wiki.deegree.org/deegreeWiki/InspireNode
>>
>>>
>>> Thanks
>>>
>>> Steve Cameron
>>>
>>> -----Original Message-----
>>> From: Markus Schneider [mailto:sch...@la...]
>>> Sent: Tuesday, 21 December 2010 10:18 PM
>>> To: dee...@li...
>>> Subject: Re: [deegree-users] FW: deegree 3 postgis datastore config
>>> example
>>>
>>> Hi Stephen,
>>>
>>> configuration examples for the PostGISFeatureStore can be found here [1].
>>>
>>>
>>> However, I am afraid that you have to hold your breath a little longer :-( In deegree 3.0, only BLOB mode and relational mapping for *simple feature types* is ready (GeometryProperty / SimpleProperty elements).
>>> The config options you stumbled upon (CodeProperty, CustomMapping, ...) only work partially and were until now only used to test some ideas on complex relational mapping configuration.
>>>
>>> We hope to make progress on the complex relational mapping in January, so it should become available in 3.1 (February) [2].
>>>
>>> If you're interested, I can sent the deegree 3 configuration for the Philosopher example to the list, once I find the time to start working on that again, so we can discuss some ideas.
>>>
>>> Best regards,
>>> Markus
>>>
>>> [1]
>>> http://wiki.deegree.org/deegreeWiki/deegree3/WorkspaceConfiguration/Fe
>>> atureStoreConfiguration#PostGISfeaturestores
>>> [2] http://wiki.deegree.org/deegreeWiki/deegree3/Roadmap
>>>
>>> Am 21.12.2010 11:59, schrieb Stephen Cameron:
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I just looked at the xml schema for the deegree 3 postgis datastore config.
>>>>
>>>>
>>>>
>>>> Is there possibly a simple 'demo' example of an actual config file
>>>> (akin to the old philosophers example)?
>>>>
>>>>
>>>>
>>>> At first glance it looks very interesting, I am keen to try to use it!
>>>>
>>>>
>>>>
>>>> Particularly this bit  looks like something I have been asking for J
>>>>
>>>>
>>>>
>>>>   <!-- === Code property declaration / mapping === -->
>>>>
>>>>   <element name="CodeProperty"
>>>> substitutionGroup="postgisfs:AbstractProperty">
>>>>
>>>>     <complexType>
>>>>
>>>>       <annotation>
>>>>
>>>>         <documentation>Definition of a code-valued property of a
>>>> feature type.</documentation>
>>>>
>>>>         <appinfo>
>>>>
>>>>           <jaxb:class name="CodePropertyDecl"/>
>>>>
>>>>         </appinfo>
>>>>
>>>>       </annotation>
>>>>
>>>>       <complexContent>
>>>>
>>>>         <extension base="postgisfs:AbstractPropertyType">
>>>>
>>>>           <attribute name="codeSpaceMapping" type="string"
>>>> use="optional">
>>>>
>>>>             <annotation>
>>>>
>>>>               <documentation>Mapping expression for the codeSpace
>>>> attribute.</documentation>
>>>>
>>>>             </annotation>
>>>>
>>>>           </attribute>
>>>>
>>>>         </extension>
>>>>
>>>>       </complexContent>
>>>>
>>>>     </complexType>
>>>>
>>>>   </element>
>>>>
>>>>
>>>>
>>>> Also the mapping elements based on the following, how does this work??
>>>>
>>>>
>>>>
>>>>   <element name="AbstractCustomMapping" abstract="true"
>>>> type="postgisfs:AbstractCustomMappingType"/>
>>>>
>>>>   <complexType name="AbstractCustomMappingType">
>>>>
>>>>     <annotation>
>>>>
>>>>       <documentation>Defines the mapping for (a part of) a custom
>>>> property.</documentation>
>>>>
>>>>       <appinfo>
>>>>
>>>>         <jaxb:class name="CustomMapping"/>
>>>>
>>>>       </appinfo>
>>>>
>>>>     </annotation>
>>>>
>>>>     <attribute name="path" type="string" use="required">
>>>>
>>>>       <annotation>
>>>>
>>>>         <documentation>(Relative) XPath targeted by this
>>>> mapping.</documentation>
>>>>
>>>>       </annotation>
>>>>
>>>>     </attribute>
>>>>
>>>>     <attribute name="mapping" type="string">
>>>>
>>>>       <annotation>
>>>>
>>>>         <documentation>Mapping expression.</documentation>
>>>>
>>>>       </annotation>
>>>>
>>>>     </attribute>
>>>>
>>>>   </complexType>
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> Steve Cameron
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> -
>>>> --------
>>>> Lotusphere 2011
>>>> Register now for Lotusphere 2011 and learn how to connect the dots,
>>>> take your collaborative environment to the next level, and enter the
>>>> era of Social Business.
>>>> http://p.sf.net/sfu/lotusphere-d2d
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> deegree-users mailing list
>>>> dee...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/deegree-users
>>>
>>>
>>> --
>>> l a t / l o n  GmbH
>>> Aennchenstrasse 19                 53177 Bonn, Germany
>>> phone ++49 +228 18496-0            fax ++49 +228 18496-29
>>> http://www.lat-lon.de              http://www.deegree.org
>>> Follow deegree on Twitter: http://twitter.com/deegree_org
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> Lotusphere 2011
>>> Register now for Lotusphere 2011 and learn how to connect the dots,
>>> take your collaborative environment to the next level, and enter the
>>> era of Social Business.
>>> http://p.sf.net/sfu/lotusphere-d2d
>>> _______________________________________________
>>> deegree-users mailing list
>>> dee...@li...
>>> https://lists.sourceforge.net/lists/listinfo/deegree-users
>>
>>
>> --
>> l a t / l o n  GmbH
>> Aennchenstrasse 19                 53177 Bonn, Germany
>> phone ++49 +228 18496-0            fax ++49 +228 18496-29
>> http://www.lat-lon.de              http://www.deegree.org
>> Follow deegree on Twitter: http://twitter.com/deegree_org
>>
>


------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
deegree-users mailing list
dee...@li...
https://lists.sourceforge.net/lists/listinfo/deegree-users

[Xsltforms-support] Annoying carriage return in rev 471 and newer

[Grégoire C. <gco...@gm...>]

Hi!

First, happy new year to all! Second, there's an annoying carriage return
generated in XSLTForms rev 471 and above. It is in:

    <xsl:when test="$appearance = 'span'">
        <span>
            <xsl:call-template name="genid"/>
            <xsl:call-template name="comunLabel"/>
            <xsl:choose>
                <xsl:when test="count(./node()) &gt;
0"><xsl:apply-templates/>
                </xsl:when>
                <!-- <xsl:otherwise><xsl:text/></xsl:otherwise> -->
            </xsl:choose>
*            <xsl:text>&#xA0;</xsl:text>*
        </span>
    </xsl:when>

As can be seen here, this character is always generated, even when you
specify a label (and this breaks my form's layout). Moreover it seems
redundant with the added "otherwise" test in "trigger-submit.xsl", which
adds a carriage return if the xforms:label tag is missing.

Grégoire
PS : thank you Alain for the quick fix in rev 474.

Re: [Xsltforms-support] external css stylesheets

[ac <ac...@hy...>]

Hi Alain,

I was mistaken in thinking that <nocss/> meant not to copy css links, 
but now, I guess that it means no in-line header css, probably.

I got the latest version from the SVN SF repo.

Warnings are just warnings indeed.  I am getting them from FireFox though.

Now the stylesheets are being applied.

Thank you.
Best wishes.

Regards,
Andre



> Le 27/12/2010 17:42, ac a écrit :
>> Hi,
>>
>> The version that I am using is the one currently available from your 
>> site and sourceforge (BetaRC3), but it is like I showed you and not 
>> like what you sent me, as below.
>>
>> Where can I get the latest version?
>
> The online version at agencexml.com is clearly an old one but still 
> good for the examples...
>
> The Beta3RC already contained <xsl:apply-templates 
> select="xhtml:head/xhtml:style | xhtml:head/xhtml:link | head/style | 
> head/link"/>
>
> The latest build is available in the SVN SF repository at 
> http://xsltforms.svn.sourceforge.net/viewvc/xsltforms/branches/dataisland/build/
>>
>> Looking at your code below, I cannot see how my css stylesheets could 
>> be applied without adding
>> <xsl:copy-of select="*/xhtml:link | */link"/>
>> as can currently do with BetaRC3.
> There is a template for that:
>
> <xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
> match="xhtml:link[@type='text/css' and @rel='stylesheet'] | 
> link[@type='text/css' and @rel='stylesheet']">
> <xsl:choose>
> <xsl:when test="$config/options/nocss">
> <xsl:copy-of select="."/>
> </xsl:when>
> <xsl:when 
> test="translate(normalize-space(/processing-instruction('css-conversion')[1]), 
> 'YESNO ', 'yesno')='no'">
> <xsl:copy-of select="."/>
> </xsl:when>
> <xsl:otherwise>
> <style type="text/css">
> <xsl:call-template name="cssconv">
> <xsl:with-param name="input" 
> select="normalize-space(document(@href,/)/*)"/>
> </xsl:call-template>
> </style>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:template>
>
> As you can see, when the nocss option is set, an xsl:copy-of is performed!
>> The xsltforms.css is also still giving me the css error warnings below:
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 72
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 83
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 101
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 135
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 174
>>
>> Avertissement : Erreur d'analyse de la valeur pour « filter ».  
>> Déclaration abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 185
>>
>> Avertissement : Propriété « -moz-opacity » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 187
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 224
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 245
>>
>> Avertissement : Erreur d'analyse de la valeur pour « filter ».  
>> Déclaration abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 291
>>
>> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
>> abandonnée.
>> Fichier Source : 
>> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>>
>> Ligne : 296
>
> Those properties are there for compatibility with FireFox: 
> https://developer.mozilla.org/en/CSS/box-sizing
>
> They're just warnings, right?
>
> Thanks!
>
> -Alain

Re: [Xsltforms-support] external css stylesheets

[COUTHURES A. <ala...@ag...>]

Le 27/12/2010 17:42, ac a écrit :
> Hi,
>
> The version that I am using is the one currently available from your 
> site and sourceforge (BetaRC3), but it is like I showed you and not 
> like what you sent me, as below.
>
> Where can I get the latest version?

The online version at agencexml.com is clearly an old one but still good 
for the examples...

The Beta3RC already contained <xsl:apply-templates 
select="xhtml:head/xhtml:style | xhtml:head/xhtml:link | head/style | 
head/link"/>

The latest build is available in the SVN SF repository at 
http://xsltforms.svn.sourceforge.net/viewvc/xsltforms/branches/dataisland/build/
>
> Looking at your code below, I cannot see how my css stylesheets could 
> be applied without adding
> <xsl:copy-of select="*/xhtml:link | */link"/>
> as can currently do with BetaRC3.
There is a template for that:

<xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
match="xhtml:link[@type='text/css' and @rel='stylesheet'] | 
link[@type='text/css' and @rel='stylesheet']">
<xsl:choose>
<xsl:when test="$config/options/nocss">
<xsl:copy-of select="."/>
</xsl:when>
<xsl:when 
test="translate(normalize-space(/processing-instruction('css-conversion')[1]), 
'YESNO ', 'yesno')='no'">
<xsl:copy-of select="."/>
</xsl:when>
<xsl:otherwise>
<style type="text/css">
<xsl:call-template name="cssconv">
<xsl:with-param name="input" select="normalize-space(document(@href,/)/*)"/>
</xsl:call-template>
</style>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

As you can see, when the nocss option is set, an xsl:copy-of is performed!
> The xsltforms.css is also still giving me the css error warnings below:
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 72
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 83
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 101
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 135
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 174
>
> Avertissement : Erreur d'analyse de la valeur pour « filter ».  
> Déclaration abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 185
>
> Avertissement : Propriété « -moz-opacity » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 187
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 224
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 245
>
> Avertissement : Erreur d'analyse de la valeur pour « filter ».  
> Déclaration abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 291
>
> Avertissement : Propriété « box-sizing » inconnue.  Déclaration 
> abandonnée.
> Fichier Source : 
> file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 
>
> Ligne : 296

Those properties are there for compatibility with FireFox: 
https://developer.mozilla.org/en/CSS/box-sizing

They're just warnings, right?

Thanks!

-Alain

Re: [Xsltforms-support] external css stylesheets

[ac <ac...@hy...>]

Hi,

The version that I am using is the one currently available from your 
site and sourceforge (BetaRC3), but it is like I showed you and not like 
what you sent me, as below.

Where can I get the latest version?

Looking at your code below, I cannot see how my css stylesheets could be 
applied without adding
<xsl:copy-of select="*/xhtml:link | */link"/>
as can currently do with BetaRC3.


Also,

The xsltforms.css is also still giving me the css error warnings below:

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 72

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 83

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 101

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 135

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 174

Avertissement : Erreur d'analyse de la valeur pour « filter ».  
Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 185

Avertissement : Propriété « -moz-opacity » inconnue.  Déclaration 
abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 187

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 224

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 245

Avertissement : Erreur d'analyse de la valeur pour « filter ».  
Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 291

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css 

Ligne : 296

Help is appreciated.
Thank you.

Regards,
ac




> Hi,
>> For example, in the xsltforms.xsl file (line 98+), couldn't one have 
>> something like:
>>
>> ...
>> <head>
>> <xsl:copy-of select="xhtml:head/@* | head/@*"/>
>> <xsl:copy-of select="*/xhtml:meta | */meta"/>
>> <link 
>> type="text/css"href="{$resourcesdir}xsltforms.css"rel="stylesheet"/>
>> <xsl:copy-of select="*/xhtml:link | */link"/>
>> ...
>>
> You are using an old version of XSLTForms and now, in the latest 
> build, this is like this:
>
> <head>
> <xsl:copy-of select="xhtml:head/@* | head/@*"/>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <xsl:copy-of select="xhtml:meta[@http-equiv != 'Content-Type'] | 
> head/meta[@http-equiv != 'Content-Type']"/>
> <link type="text/css" href="{$resourcesdir}xsltforms.css" 
> rel="stylesheet"/>
> <xsl:apply-templates select="xhtml:head/xhtml:*[local-name() != 
> 'script' and local-name() != 'style' and local-name() != 'link' and 
> local-name() != 'meta'] | xhtml:head/comment() | head/title | 
> head/comment()" mode="nons"/>
> <xsl:apply-templates select="xhtml:head/xhtml:style | 
> xhtml:head/xhtml:link | head/style | head/link"/>
> <script src="{$resourcesdir}xsltforms.js" type="text/javascript">/* 
> */</script>
>
> Link directives are interpreted by the XSLT stylesheet unless the 
> <nocss/> option is set in the config.xsl file.
>
> -Alain
>

Re: [Xsltforms-support] external css stylesheets

[COUTHURES A. <ala...@ag...>]

Hi,
> For example, in the xsltforms.xsl file (line 98+), couldn't one have 
> something like:
>
> ...
> <head>
> <xsl:copy-of select="xhtml:head/@* | head/@*"/>
> <xsl:copy-of select="*/xhtml:meta | */meta"/>
> <link type="text/css"href="{$resourcesdir}xsltforms.css"rel="stylesheet"/>
> <xsl:copy-of select="*/xhtml:link | */link"/>
> ...
>
You are using an old version of XSLTForms and now, in the latest build, 
this is like this:

<head>
<xsl:copy-of select="xhtml:head/@* | head/@*"/>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<xsl:copy-of select="xhtml:meta[@http-equiv != 'Content-Type'] | 
head/meta[@http-equiv != 'Content-Type']"/>
<link type="text/css" href="{$resourcesdir}xsltforms.css" rel="stylesheet"/>
<xsl:apply-templates select="xhtml:head/xhtml:*[local-name() != 'script' 
and local-name() != 'style' and local-name() != 'link' and local-name() 
!= 'meta'] | xhtml:head/comment() | head/title | head/comment()" 
mode="nons"/>
<xsl:apply-templates select="xhtml:head/xhtml:style | 
xhtml:head/xhtml:link | head/style | head/link"/>
<script src="{$resourcesdir}xsltforms.js" type="text/javascript">/* 
*/</script>

Link directives are interpreted by the XSLT stylesheet unless the 
<nocss/> option is set in the config.xsl file.

-Alain

Re: [Xsltforms-support] external css stylesheets

[ac <ac...@hy...>]

Hi,

To try to better explain the situation, the xsltforms forms are on web 
site that is on a portal.  The portal has global css stylesheet(s), each 
web site has its own css stylesheet(s) that overwrite elements of the 
portal stylesheet that need to be overwritten, and each forms can have 
its own css stylesheet(s) to further overwrite required styling rules.  
All these stylesheets need to be considered when rendering the xsltforms 
forms.  PIs could be used for external css stylesheets but currently, 
xhtml link elements are used as in <link type="text/css" href="abc.css" 
rel="stylesheet"/>.

How can we best ensure that all css stylesheets are properly considered 
and cascaded, for the forms?

Thank you.

Regards,
Andre





I am sorry, but I do not quite understand.

For example, in the xsltforms.xsl file (line 98+), couldn't one have 
something like:

...
<head>
<xsl:copy-of select="xhtml:head/@* | head/@*"/>
<xsl:copy-of select="*/xhtml:meta | */meta"/>
<link type="text/css"href="{$resourcesdir}xsltforms.css"rel="stylesheet"/>
<xsl:copy-of select="*/xhtml:link | */link"/>
...

The source form is well formed xhtml, and there are no css directive to 
interpret, are there?

Thank you,
ac


> Hello,
>
> Le 27/12/2010 06:58, ac a écrit :
>> Hi,
>>
>> Is there a good reason why references to external css stylesheets, in an
>> XSLTForm are not copied to the xhtml:head, by xsltforms.xsl, so that
>> xsltforms can use external css stylesheets?
> Yes, because XSLTForms can interpret CSS directives for XForms 
> elements using the syntax for namespaces (xf|trigger for example) as 
> the Mozilla extension does.
>
> Because this is performed by the XSLT stylesheet, the external files 
> are read with the document() XSLT function which requires the file to 
> be a well-formed XML document.
>
> This can be deactivated in the config.xsl files. Have a look at 
> http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions
>> A corollary to this question would be why not also copy meta tags?
> Meta tags should be copied. Can you send a test case for this issue?
>
> Thanks!
>
> -Alain
>

Re: [Xsltforms-support] external css stylesheets

[ac <ac...@hy...>]

Hi,

Why am I getting css error warnings on xsltforms.css, like:

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 72

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 83

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 101

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 135

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 174

Avertissement : Erreur d'analyse de la valeur pour « filter ».  
Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 185

Avertissement : Propriété « -moz-opacity » inconnue.  Déclaration 
abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 187

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 224

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 245

Avertissement : Erreur d'analyse de la valeur pour « filter ».  
Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 291

Avertissement : Propriété « box-sizing » inconnue.  Déclaration abandonnée.
Fichier Source : 
file:///C:/dev/jboss-3.2.5/server/default/deploy/html.ear/html.war/library/hyperform/stratml/asset/xsltforms/xsltforms.css
Ligne : 296

Thank you,
ac

Re: [Xsltforms-support] external css stylesheets

[ac <ac...@hy...>]

Hi,

I am sorry, but I do not quite understand.

For example, in the xsltforms.xsl file (line 98+), couldn't one have 
something like:

...
<head>
<xsl:copy-of select="xhtml:head/@* | head/@*"/>
<xsl:copy-of select="*/xhtml:meta | */meta"/>
<link type="text/css"href="{$resourcesdir}xsltforms.css"rel="stylesheet"/>
<xsl:copy-of select="*/xhtml:link | */link"/>
...

The source form is well formed xhtml, and there are no css directive to 
interpret, are there?

Thank you,
ac


> Hello,
>
> Le 27/12/2010 06:58, ac a écrit :
>> Hi,
>>
>> Is there a good reason why references to external css stylesheets, in an
>> XSLTForm are not copied to the xhtml:head, by xsltforms.xsl, so that
>> xsltforms can use external css stylesheets?
> Yes, because XSLTForms can interpret CSS directives for XForms 
> elements using the syntax for namespaces (xf|trigger for example) as 
> the Mozilla extension does.
>
> Because this is performed by the XSLT stylesheet, the external files 
> are read with the document() XSLT function which requires the file to 
> be a well-formed XML document.
>
> This can be deactivated in the config.xsl files. Have a look at 
> http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions
>> A corollary to this question would be why not also copy meta tags?
> Meta tags should be copied. Can you send a test case for this issue?
>
> Thanks!
>
> -Alain
>

Re: [Xsltforms-support] external css stylesheets

[COUTHURES A. <ala...@ag...>]

Hello,

Le 27/12/2010 06:58, ac a écrit :
> Hi,
>
> Is there a good reason why references to external css stylesheets, in an
> XSLTForm are not copied to the xhtml:head, by xsltforms.xsl, so that
> xsltforms can use external css stylesheets?
Yes, because XSLTForms can interpret CSS directives for XForms elements 
using the syntax for namespaces (xf|trigger for example) as the Mozilla 
extension does.

Because this is performed by the XSLT stylesheet, the external files are 
read with the document() XSLT function which requires the file to be a 
well-formed XML document.

This can be deactivated in the config.xsl files. Have a look at 
http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions
> A corollary to this question would be why not also copy meta tags?
Meta tags should be copied. Can you send a test case for this issue?

Thanks!

-Alain

[Xsltforms-support] external css stylesheets

[ac <ac...@hy...>]

Hi,

Is there a good reason why references to external css stylesheets, in an 
XSLTForm are not copied to the xhtml:head, by xsltforms.xsl, so that 
xsltforms can use external css stylesheets?

A corollary to this question would be why not also copy meta tags?

Thank you
ac

Re: [Xsltforms-support] IE8 Performance on XSLTForms beta-3

[<fr...@fl...>]

Hi all,

The 471 version indeed boosted performance for my application with a  
10000 line instance. Under IE8 the loading time is now 40 seconds, too  
much for operational use, but that is coming within reach.

The amazing part is the performance under FF: 3.6 seconds. More than a  
factor 10 faster. Does anyone have a clue why that is?

Good days!

Fred



Citeren Grégoire COLBERT <gco...@gm...>:

> Hi!
>
> I've read the discussion but cannot sort this out in my mind : is this
> performance issue, that you are talking about, due to the fact that we
> cannot refresh a single model? I mean the emptiness of the
> "XFModel.prototype.refresh"  function at the moment. Or is it not related?
>
> Thanks!
> Grégoire
>
>
> Le 21/12/2010 11:37, Santosh Chandak a écrit :
>> Thanks Alain. For our form, we can not remove // from all the places
>> because we have nested xml.
>> Regarding the solution to refresh select part of the page, I could
>> implement it by passing hint on selecting the parent node for a
>> particular form control and it is working great. I simply pass a
>> number (depending on all the dependencies) on focus event which would
>> help in determining the parent node to be refreshed.
>> Below is the code snippet -
>> A trigger on form has -
>> <xf:setvalue ev:event="DOMActivate"
>> ref="instance('datapad')/@parentIndex" value="4"/>
>>
>> And in xsltforms.js -
>> XFControl.prototype.focus has -
>> xforms.selectedElement = this.element;
>>
>> refresh method has -
>>
>> var parentIndex = Util.getParentIndex();         // returns
>> instance('datapad')/@parentIndex
>>         if(!this.selectedElement || parentIndex == "-1")  {
>>             this.selectedElement = this.body; // Can be optimized further
>>         } else {
>>               for(var i = 0; i < parentIndex; i++) {
>>                 this.selectedElement = this.selectedElement.parentNode;
>>               }
>>         }
>>         this.build(this.selectedElement,
>> (this.defaultModel.getInstanceDocument() ?
>> this.defaultModel.getInstanceDocument().documentElement : null), true);
>>         Util.setParentIndex("-1");
>>
>>
>> All we need to do is pass appropriate parentIndex from the form and it
>> should resolve the performance issues caused by refreshing the entire
>> page. I hope something on these lines can be added to the xsltforms
>> library.
>>
>>
>>
>>
>>
>> On Fri, Dec 17, 2010 at 1:00 AM, COUTHURES Alain
>> <ala...@ag... <mailto:ala...@ag...>>
>> wrote:
>>
>>     Hi Santosh,
>>
>>>     I think reducing use of // and using multiple models might be
>>>     able to help but would not resolve the issue when form is big.
>>>
>>     This can resolve this issue when data is big...
>>
>>>     In our case, we might not be able to test with multiple models
>>>     unless nested models are supported (I think nested models are not
>>>     supported in Xforms 1.1)
>>>
>>     I don't understand what you mean with nested models but nested
>>     forms are considered for next XForms versions.
>>
>>>
>>>
>>>     I debugged the code and came to know the main reason for
>>>     XSLTForms being slow is because for every change, it tries to
>>>     refresh all the elements on the page. The exact location of
>>>     problem is below line in the refresh method  -
>>>
>>>     this.build(this.body, (this.defaultModel.getInstanceDocument() ?
>>>     this.defaultModel.getInstanceDocument().documentElement : null),
>>>     true);
>>>
>>>
>>>
>>>     Refresh method passes the entire HTMLBodyElement (this.body =
>>>     xforms.body = HTMLBodyElement ) every time anything is changed.
>>>     The build method gives recursive calls on all its children.
>>>
>>>     For a big form, for simple operations like change in data of a
>>>     textbox, I am seeing lots of recursive calls to the build method
>>>     and thousands of calls to  Xpath methods etc.
>>>
>>     Yes, there is no list of elements to be checked and refreshed when
>>     necessary. This can be added but this is not an easy change. The
>>     number of XPath methods calls should be reduced when reducing the
>>     use of //: I should check it myself but I'm almost sure that it's
>>     very bad for dependencies and, probably, every expression is
>>     reevaluated each time. Don't ever use //, this is my most precious
>>     advice...
>>
>>>
>>>
>>>
>>>
>>>     I think this problem can be solved with selecting the right HTML
>>>     Element every time we give call to refresh method
>>>
>>>
>>>
>>>         * Refresh HTMLBodyElement only when entire form is loaded
>>>         * For every action, we know where the Focus/blur happened,
>>>           refresh only its appropriate parent HTML element
>>>         * Binds can be handled separately. Cases where we need to
>>>           refresh other elements can be handled separately
>>>
>>     There might be reverse lists of dependencies to directly point
>>     elements to be refreshed but they wouldn't be easy to store with
>>     the native XML architecture.
>>
>>>
>>>
>>>     This should guarantee that only a select part of the page is
>>>     considered for refresh. I have tried to do it and in fact I can
>>>     see that it can be achieved, just need to determine how many
>>>     levels to go up and select the appropriate HTML parent Element.
>>>
>>     Sorry, I don't think that it would be a correct approach. This
>>     might work for your form but not for all.
>>
>>     Maybe declaring, with extra attributes, some sort of groups of
>>     elements to be refreshed together or allowing to declare that this
>>     element has to be refreshed only when a user-defined event is
>>     dispatched might help.
>>
>>     Thanks!
>>
>>     -Alain
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how
>> to connect the dots, take your collaborative environment
>> to the next level, and enter the era of Social Business.
>> http://p.sf.net/sfu/lotusphere-d2d
>>
>>
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>

[Xsltforms-support] XPath Statistics

[COUTHURES A. <ala...@ag...>]

Hello,

I have added statistics about execution times in the F1 help box.

It is indeed very interesting for locating expensive XPath expressions:

    * improvements/bugs can then be studied
    * new functions can be added

Thank you for your feedbacks!

-Alain

[Xsltforms-support] Giving credits + supporting through donations (was: F1 message box and double click in svn r470)

[Grégoire C. <gco...@gm...>]

Hi Alain,

Le 22/12/2010 07:31, COUTHURES Alain a écrit :
> XSLTForms has an LGPL license and I'm sure just few developers will
> hesitate to comment the corresponding Javascript instruction or change
> the interception again if they need to. Beginners probably won't
> change anything but won't press F1 either unless they're looking for
> help/credits!
>
> Donations for XSLTForms are inexistent and, except in Steven
> Pemberton's and Kurt Cagle's papers and in your own personal site, I
> never see any publicity or credits for it. If XSLTForms is just used
> for prototyping, F1 shouldn't be a problem at all.
>
> Do you have another suggestion?
>

In the generated HTML+JS, you could add an HTML comment saying that this
was generated with XSLTForms. Most developers look at the source when
they see something impressive. This is the only non-intrusive thing I
can think of at the moment. As I said previously, I will make a
«Credits» page on my website, giving links back to the libraries I use.
Why don't you add a paragraph on this at
http://www.agencexml.com/xsltforms ? Something like «If you use
XSLTForms please give a link to this page and support the project
financially». If you don't ask, most people will think that you don't
need anything.

While I'm at it : I would like to give money regularly to the project,
as this is my belief that when people work, they deserve money. I know
that the 20$ I gave the 20th of May were only symbolic, but living on
the Assedics isn't a "golden" situation, and I'm 100% sure that I cannot
pay for your support service.

FYI, my plan is that when my real estate website will be good enough,
the website will attract some paying visitors and I will be able to give
back to Open-Source projects a part of this money. XSLTForms is the most
important library in my project, but ATM it's really slow to refresh all
models when you have many. If you want to make XSLTForms famous (and
more easily earn money from it), you should focus on the issues of
Full-AJAX-websites building. As you know, refreshing a single model is
impossible and that means that web-apps need to be build very cleverly
in order to "factorize" refreshes (I mean that I need to use flags in my
JS code to ensure that there will only be one refresh done after a serie
of actions — and this sole refresh is already slow as I need to refresh
all models).

XSLTForms could be a «Rapid declarative AJAX-like application
development library», the only of its kind, but it's not there yet. I
would like to contribute patches to the code but it lacks comments and
it's sometimes really cryptic (this wrong-order insertion of nodes in
"XFInsert.prototype.run" just kills me). So there's really not many
options left to me. I just sent you another 20$ to show that I
appreciate the time you spend on XSLTForms. It's symbolic but what else
can I do?

Best regards,
Grégoire

Re: [Xsltforms-support] F1 message box and double click in svn r470

[Grégoire C. <gco...@gm...>]

Hi Alain,

Le 22/12/2010 07:31, COUTHURES Alain a écrit :
> XSLTForms has an LGPL license and I'm sure just few developers will
> hesitate to comment the corresponding Javascript instruction or change
> the interception again if they need to. Beginners probably won't
> change anything but won't press F1 either unless they're looking for
> help/credits!
>
> Donations for XSLTForms are inexistent and, except in Steven
> Pemberton's and Kurt Cagle's papers and in your own personal site, I
> never see any publicity or credits for it. If XSLTForms is just used
> for prototyping, F1 shouldn't be a problem at all.
>
> Do you have another suggestion?
>

In the generated HTML+JS, you could add an HTML comment saying that this
was generated with XSLTForms. Most developers look at the source when
they see something impressive. This is the only non-intrusive thing I
can think of at the moment. As I said previously, I will make a
«Credits» page on my website, giving links back to the libraries I use.
Why don't you add a paragraph on this at
http://www.agencexml.com/xsltforms ? Something like «If you use
XSLTForms please give a link to this page and support the project
financially». If you don't ask, most people will think that you don't
need anything.

While I'm at it : I would like to give money regularly to the project,
as this is my belief that when people work, they deserve money. I know
that the 20$ I gave the 20th of May were only symbolic, but living on
the Assedics isn't a "golden" situation, and I'm 100% sure that I cannot
pay for your support service.

FYI, my plan is that when my real estate website will be good enough,
the website will attract some paying visitors and I will be able to give
back to Open-Source projects a part of this money. XSLTForms is the most
important library in my project, but ATM it's really slow to refresh all
models when you have many. If you want to make XSLTForms famous (and
more easily earn money from it), you should focus on the issues of
Full-AJAX-websites building. As you know, refreshing a single model is
impossible and that means that web-apps need to be build very cleverly
in order to "factorize" refreshes (I mean that I need to use flags in my
JS code to ensure that there will only be one refresh done after a serie
of actions --- and this sole refresh is already slow as I need to
refresh all models).

XSLTForms could be a «Rapid declarative AJAX-like application
development library», the only of its kind, but it's not there yet. I
would like to contribute patches to the code but it lacks comments and
it's sometimes really cryptic (this wrong-order insertion of nodes in
"XFInsert.prototype.run" just kills me). So there's really not many
options left to me. I just sent you another 20$ to show that I
appreciate the time you spend on XSLTForms. It's symbolic but what else
can I do?

Best regards,
Grégoire

Re: [Xsltforms-support] F1 message box and double click in svn r470

[COUTHURES A. <ala...@ag...>]

Le 21/12/2010 23:37, Leigh L Klotz Jr a écrit :
> It would be nice if you'd offer a different way for us to give AgenceXML
> credit.
> It's fairly intrusive for a library to take over double click and F1.
>
Double click is not mentioned in XForms specifications but was probably 
too intrusive because it might happen accidentally so I changed it to F1 
instead.

Browsers already intercept F1 for their own help/credits and some 
analysis I fund said that it usually was involuntary. The other function 
keys seem more useful and Opera is defining all of them!

What else? A splash box wouldn't be nice, of course... Neither a static 
line at the end of each page...

BTW, this message box shouldn't only display credits but also specific 
debug statistics such as:

    * size of instances
    * Javascript loading time
    * cumulative refresh time
    * longest XPath expression evaluation times

XSLTForms has an LGPL license and I'm sure just few developers will 
hesitate to comment the corresponding Javascript instruction or change 
the interception again if they need to. Beginners probably won't change 
anything but won't press F1 either unless they're looking for help/credits!

Donations for XSLTForms are inexistent and, except in Steven Pemberton's 
and Kurt Cagle's papers and in your own personal site, I never see any 
publicity or credits for it. If XSLTForms is just used for prototyping, 
F1 shouldn't be a problem at all.

Do you have another suggestion?

Thanks!

-Alain