inseefr / eno Goto Github PK

The usage of this driver is weird and it is not at all generic.
It creates two xforms controls from a unique ResponseDomain.
And it indicates that the select values can only be between 20 and 60 in the output.
The driver is not reusable in that state.

There are a lot of comments in the xslt stylesheets.
The useless comments must be removed.
In the future, if possible, branches must be used to keep some code that could be used later rather than keeping it in the master branch in comments.

Is is exactly the same that the default Bind template but with a non used variable some code in comments using this variable.

The second one was inspired by the first one.
And the first isn't completely compliant with the Eno architecture.

In theory, the Table driver should write some elements, call some functions and continue the process with the children of the input.
Those children will call some other drivers, etc....

When I wrote the functionnality, I could not manage to do that, so I use a function to directly get the elements I needed as children and do the treatment within the Table Driver.
Some functions on the DDI side are a little weird.

It will be an improvement to refactor that part.

Miscellanous parameters and anticipation of DDI 3.3.

Development of XMLPogues to DDI
Integration of XMLPogues to DDI
Development of DDI to XMLPogues
Integration of DDI to XMLPogues

The xsl stylesheets are currently generated this way :

• a main xslt stylesheet named '...-fixed.xsl' contains the namespaces that are used by the final generated xsl stylesheet (and complex templates that cannot be generated)
• one or several xsl stylesheets are generated from fods files, but without namespaces so they cannot be used in that state
• the final generated stylesheet is built by copying the '...-fixed.xsl' stylesheet and adding it the content of the generated stylesheets (so it contains namespaces and can be used).

Maybe it could be done another way (to be discussed) :

• a stylesheet containing the complex templates and importing the stylesheets to be generated
• one or several stylesheets generated from fods files : the namespaces of those stylesheets could be placed in a second spreadsheet of the fods file
  The fods2xsl transformation would be more standalone this way. For the moment it cannot generate a functional stylesheet by itself.

Formalize process with XProc or equivalent.
Definition of a parameter file format (XSD / Schematron)

Do we need to create an init submission which will be called in a xforms-ready action to init the instance ?

DDI2XMLPogues transformation.

Simpsons v2 questionnaire
Filters questionnaire

This requires to dynamically create the folder before processing and to delete it afterwards.

If not, the corresponding template must be modified, and can probably be mutualized with another one.

For example, the alert message :
'You shall type an integer number between x and y" is written a lot in the resource instance.
It should be possible to do something approximately like this :

1. write only once in the resource instance :
   You shall type an integer number between
   and
2. call the alert message like this in the xforms element :
   <xf:alert value="concat($form-resources/messageA, x, $form-resources/messageB, y)"/>
   Approximately...

Would it really decrease the size of the questionnaire ?
Would it be faster/slower/the same ?

For the empty xd:desc elements, and the complex templates.

This branch was used to prevent empty Xforms element to be written in the output (output/fr/models.xsl).
It lightens considerably the generated questionnaire.
If possible, it'll be an improvement if it was taken into account.

A high level introduction to Eno

It is a well-known open-source practice. See for example https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/FSDiskFullWriteError.java#L1

Folder reorganization
Enhancement of XSLT import mechanism
Enrichment of in-getter/out-getter mapping

Here we have a zip file holding a version of the Simpsons questionnaire, but it has been recently pushed in another - and more appropriate ? - location, so i guess the zip file can be deleted.

Some drivers are named as if they produced elements of the XForms namespace, whereas in fact they are not. This should be documented.

Example: xf-double-duree.

Including CSS upgrade to target Orbeon version

It is the template on xhtml:a.
It seems to me that it is not correctly placed.
Is it really dereferencing ?
Wouldn't it be more appropriate to :

• create a driver in some way to write the HTML in models.xsl ?
• or at least to move it in cleaning.xsl where some templates linked to xhtml:a elements are already present ?

Is it possible to separate the main instance in two ?

• some elements are linked to fields and can be filled by end users
• some elements are linked to fixed texts and will never change
  Only the first type of elements need to be saved.
  The other elements could be put into a second instance.
  Two gains :

1. only the data that needs to be saved is saved, it will increase the performances
2. there are less adherences between the form and the data stored in base. If for example we want to change an id element for an unknown reason, it is possible. It's not possible if there is such a mention in base.

And is it possible to flatten the instance ? It will be necessary if we want to remove id sections of the main instance.

There might be something to do with :

• the multiple templates with enoddi:get-label mode and the creation of labels from QuestionText, ordinary Instruction, 'format' Instruction and 'tooltip' instruction.
• the multiple templates with lang-choice mode which are multiplied due the comlpexity described above

It might be impacted by issue #54.
It might help if the labels on the DDI side were harmonized.
Maybe something better or simpler could be done on the produced xhtml.

For the empty xd:desc elements, and eventually within the complex templates.

It is a very good idea of @BulotF.
It does seem a little counter-intuitive since, for example, a QuestionItem with a TextDomain response seems very close to an xf:input field.
But it will allow to delete a lot of templates which will become useless and to simplify a lot of other templates. It will increase the readability of parts of Eno.
It will have a big impact on the produced Xforms.

5 warnings raised by OSSRH during Eno publication:

• fr\insee\eno\Constants.java:150: no @param for path (getInputStreamFromPath
• fr\insee\eno\xsl\FodsToXSLCompiler.java:33: no description for @param args
• fr\insee\eno\xsl\FodsToXSLCompiler.java:418: no description for @throws Exception
• fr\insee\eno\xsl\FodsToXSLCompiler.java:524: no description for @throws Exception
• fr\insee\eno\xsl\FodsToXSLCompiler.java:621: no description for @ThrowsException

But it would be better to take care of #59 and #61 before doing that.
And this file will probably know a lot of change with Eno producing more outputs.

It could be difficult but it would be more appropriate to build the control in ddi2fr.xsl by calling different ddi functions (existing or not).

Look for a way to internationalize the controlled vocabulary used by eno.
It might not be doable but it needs to be investigated.

Lang conf files are duplicated in both src/lang/fr and src/resources/lang/fr, should keep only one copy of it.

It has only one implementation for the moment so it can be easily renamed.
If the enofr:get-help function needs to be linked to another function or element, it would have to be handled in ddi2fr-fixed.xsl.

Make dynamic tables appear with at least @minimumrequired lines

At least in README.md.

A comment in the code seems to tell that the behaviour should be parametable.
A parameter needs to be created on a questionnaire level (in parameters.xml file) and used in models.xsl to know if the behaviour is wanted or not.

Because it isn't appropriately named.
But I have no good idea !

Bug fixes:

• management of error messages for deactivable questions
• dynamic tables

Good Job!!!!
Ed

It should return the values 'radio-button', 'drop-down-list' and 'checkbox' and not the values 'full' and 'minimal'.
The enofr:get-appearance function must not be directly linked to the enoddi:get-output-format.
The values 'full' and 'minimal' must be deduced from enoddi:get-output-format and enoddi:get-type in ddi2fr-fixed.xsl.

The enoddi:get-codes-first-dimension getter doesn't return consistent result between Table and TableLoop driver.
In the first case it's a sequence of <l:Code/> that are returned, on the other it's a sequence of elements (used only to render the number of lines).
In the ddi2fr implementation, the TableLoop driver never use this getter but still it's a bit confusing for new implementation.
This getter should return consistent results from both driver (in the ddi2fr implementation, a dummy sequence is enough as l:Code are never used through this getter, only the number of lines is used).

This element is misplaced since it doesn't need to be saved.
It needs to be moved to fr-form-util.