CRUD forms for non-MODS XML datastreams #145
Comments
|
I fully agree with you Mark. XML forms is a corner stone of current Islandora and in our specific case, by managing research data, curation is moving fast from central managed to self-data-originator curation. This means keeping a flexible way of updating XML datastreams, even when FF is RDF based, is very important to keep interest in multiuser environments where the UI experience is fundamental. Keeping XML forms would also help in migration/early adoption, by allowing new modules to reuse existing input workflows. We are using XML forms for Darwin Core and EML also. E.g, i can't think of practical way of making a complex EML schema form using only the drupal provided form elements/entity fields or add-ons like the webforms module for this purpose. |
|
I'm guessing no one understood that this one is pretty much implicit? What would Islandora be without being able to edit metadata :) We're focusing on the indexing and display of data first, and then administration later. There will still be the ability to edit your metadata, and to work with metadata of any type you desire. It just won't be done using XML forms. Much of the functionality is going to get pushed down to the middleware layer, but you will still be able to do all the old things. Also, I want to stress that although Fedora 4 is RDF based, we in no way are pushing Islandora to use purely RDF metadata. We plan on fully supporting XML based datastreams in conjunction with the RDF. We are not converting xml to other formats behind the scenes and recreating it on the fly when requested, or anything else of the sort. Your xml will be preserved in Fedora, just as it is now. |
|
I understood it was implicit, but I filed this issue to make it explicit =8^). |
|
Right daniel, thanks for the clarification =) , but right now in this stage, where we all are still trying to get used to this real middleware idea and making some sort of brain-storming here, because implicit means "not verbalised". I understand we will be able to do all the things we did in the past in the same or better way, if not, the it's not islandora anymore, If xml forms or another better way, i just wanted to implicitly state that there are some things that need to be discussed, indexing and displaying is fine, but giving users a way out-of-box of keeping a way UI ingestion in place is fundamental. So for my use case this is also priority. |
|
Oh absolutely guys. No worries. Your use cases are definitely in line with the vast majority of the community and are important. The point I was really trying to drive home is that 'no XML forms' doesn't mean 'no XML metadata support'. We're not driving a hard line with Fedora 4 and RDF simply for convenience or simplicity on the programming side. |
|
This may be a stupid question, but will the metadata live in Drupal or Fedora4 or both? Could a javascript base XML editor be wrapped in a Drupal Module (I'm thinking of our viewer modules):
Diego's comment about representing complex XML using standard Drupal form fields is right on I think. I may do a little testing there. |
|
The full xml file will live in Fedora. A sliced up version will live in Drupal, just like how we slice it up to get into Solr. Oh ye of little faith :D Let's at least try. We really can't afford to maintain xml forms. Doing it with Drupal, or at least other 3rd party machinery is definitely the way to go. |
|
Just found this. From one of islandora's original developers, no less: https://github.com/alxp/xpath_field |
|
[Feeds Extensible Parsers]https://www.drupal.org/project/feeds_ex |
|
Both projects, @daniel-dgi and @dmoses look very promising and adaptable. Still, i would love we could rescue the panels and tabs (ajax) functionality from XML forms and also add some other widgets. And what about ingest steps? Lastly @daniel-dgi, what does mean "We really can't afford to maintain xml forms." To much work, ugly coded, unpractical (i'm so used to it, extending, hacking is so easy)? Does that mean xml forms could be community maintained? |
|
Since we're identifying approaches to import XML into Drupal, I'll thow https://github.com/mjordan/islandora_feeds into the ring. It uses intermediate nodes to map incoming data to Islandora objects so it can easily leverage the awesome power of the Feeds ecosystem, includeing https://www.drupal.org/project/feeds_xpathparser. Probably not useful as a general approach in the F4 future, but one cool feature (I think it's cool because I wrote it 😊) is that the module generates an importable Forms definition file and an .xsd file by introspecting the intermediate content type. |
|
Wow folks. Between xpath_field and something like jquery.xmleditor or doctored.js, that pretty much nails it. Although I think in due time, all possibilities need to be explored to some degree. @DiegoPino, as we adopt true Drupal integration, we can start offloading some of the monoliths we've had to build because of the Islandora's original design. It's a simple issue of maintaining as little code as possible to achieve our goals, which in the long run will help keep Islandora sustainable as a community driven project. Though I must admit, I love your idea of community involvement in XML forms. It certainly needs some love for the current version of Islandora, which isn't going away any time soon. If you or anyone else is interested, you should ping @nigelgbanks, the original author (who is now a project manager with less and less time to devote to maintenance). |
|
I'd like to move to formatting our uses cases like how the Fedora community is formatting their uses cases. Little bit of standardization, and we get to flesh things out a little bit better. So, @mjordan when you have a moment, check out the template I set-up, and edit your initial comment. You can check of an example I did here. thanks! |
Monday Feb 02, 2015 at 00:41 GMT
Originally opened as https://github.com/islandora-interest-groups/Islandora-Fedora4-Interest-Group/issues/11
Examples:
Remarks:
The text was updated successfully, but these errors were encountered: