Investigate XML editors to replace XML Forms

[daniel-dgi]

See this crazy conversation here: https://github.com/Islandora/Islandora-Fedora4-Interest-Group/issues/11

Long story short, check out jquery.xmleditor and doctored.js and see if they're any good.

Let us know if one of them is a clear winner.

[whikloj]

So I looked at jquery.xmleditor and doctored.js (demos at prior links).

Neither is great from a usability standpoint. But with doctored.js some of the UI is very obscure, like removing an element you have to click in the element and backspace to remove all the text and child elements, then you can remove the actual element.

I like jquery.xmleditor but the javascript is not ready for a Drupal environment and processing the schemas into JSON has not worked for me.

I built a small module to allow you to use the editor on an XML field in a Drupal content-type and with some modifications it works, but because of the above 2 issues (plus the fact both editors require you to edit the XML vs a nice form) I am holding off anymore actions. Further discussion is probably warranted.

[whikloj]

Here are a couple options we could mutate or build on if XML Form Builder is not the winner

1. https://github.com/davidmoten/xsd-forms (java application that generates forms using a unique schema format).
2. https://www.drupal.org/project/entityform (Drupal module, not designed to read XML or generate XML, so that would have to be built.)

[DiegoPino]

If the idea is to go for something simpler to maintain than XML Forms+objective forms then i would discard 1). It's Java, it requires that XSD's are annotated (so we would en having something very similar to our current xml forms, user will end editing every xsd definition by hand) and also does not support full xsd elements and attributes + not being maintained.
2) Could be an option, but the xml part would be missing (means generation of the form + getting xml from it).

I think jquery.xmleditor is still an option we can discuss. Also, as a community project, current objective forms + xml forms could be cleaned up (and/or converted to a single module...), simplified (getting rid of all the custom js nobody will be able to maintain) and also the ingest steps stuff could be made simpler. There is a lot of recursive back and forth callbacks that could be made simpler. I'm not criticising the current implementation, it works, and i'm sure it was a lot of work to implement, but a rebuild/rethinking of some parts could make things simpler to maintain. Just an opinion

[daniel-dgi]

That's not a bad opinion, @DiegoPino. If nothing's going to work for us out of the box and require a lot of work / maintenance, then a re-vitalized form builder can be an option on the table. A cleaned out and streamlined xml-forms would give everyone their use-cases. It's just a boatload of work and would require dedicated maintenance. We'd need to have more community involvement if we were going to go that route. If Jared and I were to take that on in addition to the workload we have now, it would single-handedly sink the project.

[DiegoPino]

@daniel-dgi your are right (110%). UI is certainly a community involvement motivator, that's for sure. Let's discuss this with the rest, i could handle at least a base prototype, but being a freelance developer i have almost the same restrictions that apply to the rest of the developers in this groups. Also a initial discussion on what is missing, too complicated, etc on the current implementation could end in a Forms-requirements document that could serve as guide to starting this development.

[daniel-dgi]

Let's bring this up at the next F4 IG meeting, then.

[ruebot]

On the agenda 😄

[DiegoPino]

Sorry folks, I could not make it to todays meeting, not even open my Skype, had to deal with volcano ash.

But a recent comment of @dmoses on #30 (comment)
👌 made me think.
I did not know until now there was an OSF implementation for Drupal. Giving the documentation a little more time i think @dmoses just hit a goldmine. There is some very useful code there.

http://wiki.opensemanticframework.org/index.php/Category:OSF_for_Drupal_User_Manual

Not completely on topic but it's look like a tangent idea/discussion:

This API does not only bring RDF from triple stores to Drupal but can manage the whole CRUD operation, back and forth, and even integrates a FORM BUILDER/entities/revisions/search for RDF based on ontologies..
So i was thinking…if Fedora4 implements Linked Data Platform 1.0 Architecture and https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API will we wrapped by Islandora using camel, then in theory we could extend OSF to talk to this new islandora-camel middleware on ingest? Options could be to extend OSF(maybe it's too much), or reuse some well written code, like the rdf terms to form mappers, rdf processor and generators and the entities stuff.

Islandora would get this way wellformed RDF directly from Drupal requiring less effort from you guys, and could just translate actions back and forth? Does any one has some time to check the code too?
I'm just starting to read the code and find some parts look very similar to what we are planning here.

[daniel-dgi]

It's definitely a possibility Diego. Someone should install it and see if it would work for us. I'm afraid it deals with RDF only, so we'd still be on the hook for some sort of form builder for MODS and PBCore and the like.

[dmoses]

I know we've discussed Form Builder ourselves as it has a fairly steep learning curve. I think we're starting at the wrong end with the desire for an XML based form builder.

I'd like to suggest that we replace the existing Islandora Form Builder module with something like the Drupal Form Builder module and tie the resulting forms to a content type or islandora/drupal ingest module or ?. No need for XML at this stage.

The metadata created could persist in Drupal, but could also mapped/exported to Fedora4/other consuming services in an appropriate format/schema using the Drupal Views Datasource module. From the module description ... "Views Datasource is a set of plugins for Drupal Views for rendering content in a number of shareable, reusable formats based on XML, JSON and XHTML. These formats allow content in a Drupal site to be easily used as data sources for Semantic Web clients and web mash-ups."

This would allow Drupal users to create forms in an intuitive manner, while at the same time bridging the content to other formats. We'd probably need to decide on a common set of potential elements/labels to start, provide a number of Views that map the Drupal data to either XML or RDF ... but it could be the base.

[dmoses]

... I've not tested either the Drupal Form Builder module or the Drupal Views Datasource module so may be full of beans.

[DiegoPino]

Hi, i'm getting more involved in this day by day. Donald, the Drupal Form Builder module is also an option as it delivers a straight drupal interface and is plug-able, we could maybe add a Xpath and CRUD interface to make this forms generate xml. Drupal Views Datasource produces schema-less XML (for what i understood reading the readme and some quick view of the code), so would have to digg in deeper to see what does this imply and if it's useful.
I would suggest the following: could we take some notes(or someone who has a more defined idea than me, my head if full right now) on what should a xml_form replacement module deliver to the community? What are the needs, musts, no-no, etc? Basicaly a requirements table, like "should it serve for RDF and XML generation"? XSD validation? Json-schema?What would it's role in the ingest/edit workflow? Only for datastreams or for FF object definitions (FF RDF too)? Should we go the big step to allow also RDF directly (in case someone wants this) as XML replacement, like MODS RDF, http://www.loc.gov/standards/mods/modsrdf/v1/modsrdf.owl.

Oh,i know, i'm always making so much questions, but i would love to scale what effort is needed before going for more ideas, this way we don' t go for a patch development that ends to be unmaintainable in the future or does not satisfies our users needs, also i don't want to reinvent the wheel, keep it as simple as possible.

[ruebot]

Would it be worth holding a special Fedora 4 IG call to discuss this topic?

[DiegoPino]

@ruebot ++

[ruebot]

Doodle poll here: https://doodle.com/p5ung6n9qidedezz

[mitchmac]

Just noticing this thread after seeing the note about the special meeting. We spent a bit of time a few years ago researching this topic when working on Islandora Sync. We settled on using Drupal nodes as the entity type for storing Fedora datastreams (binary and XML) and extended the node form to allow for XML CRUD. The XML operations form was available for each field of the node and looked like: https://raw.githubusercontent.com/wiki/Islandora/islandora_sync/files/islandora_sync-field_settings.png

There are a lot of modules in Drupal contrib that enhance node forms; Field Group and Field Collection in particular helped handle structuring fields in a way that models common XML patterns. I'm sure Sync lacks a bit of what could be done with XML Form Builder on the XML side, but having Drupal take care of the UI for fields and field structure eliminated a lot of code that Form Builder needs.

The downside to the approach taken with Sync is that the XML logic is coupled to the Drupal field structure. It may be an acceptable tradeoff though to consider a similar approach to reduce the burden of maintaining an independent XML Form like system.

[whikloj]

I like the look of the Drupal Form Builder. I haven't had a chance to build a form, but it seems fairly easy to throw together a form and a save function to do whatever you like with the data. So we would have to setup a couple forms to start with, but it seems to make it fairly easy to extend/modify or replace.

[efgramsbergen]

This looks like a natural task for xForms. I used Orbeon xForms 10 years ago and it was way better then than the XML forms are now. I haven't used it recently but it could be worthwhile to look at current xForms implementations - see http://en.wikipedia.org/wiki/XForms

[dmoses]

Has anyone checked CKEditor as an option for editing XML? There are XML Template and an XML API plugins available. This is a common/well supported editor that many users will already have installed on their sites.

[dannylamb]

Closing since D7 relatied and we're moving to 8