I'm getting an error trying to run it locally, and the output below from npm test. Missing dependency? Lib-PAPRM01:romajs hac13$ npm test

romajs@0.0.1 test /Users/hac13/Development/TEIC/romajs mocha --recursive --compilers js:babel-core/register --require ./test/setup.js

/Users/hac13/Development/TEIC/romajs/test/setup.js:1 (function (exports, require, module, __filename, __dirname) { import { jsdom } from 'jsdom'; ^^^^^^ SyntaxError: Unexpected token import at Object.exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:513:28) at loader (/Users/hac13/Development/TEIC/romajs/node_modules/babel-register/lib/node.js:144:5) at Object.require.extensions.(anonymous function) [as .js] (/Users/hac13/Development/TEIC/romajs/node_modules/babel-register/lib/node.js:154:7) at Module.load (module.js:458:32) at tryModuleLoad (module.js:417:12) at Function.Module._load (module.js:409:3) at Module.require (module.js:468:17) at require (internal/module.js:20:19) at /Users/hac13/Development/TEIC/romajs/node_modules/mocha/bin/_mocha:346:3 at Array.forEach (native) npm ERR! Test failed. See above for more details. On Wed, Apr 26, 2017 at 11:46 PM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

Dear Martina (and council),

Thank you so much for trying the prototype out! Glad to hear it holds up with more ODDs. I welcome your help with design, see below for some specific prompts.

Here is a new update for this month: https://raffazizzi.github.io/romajs/

As I mentioned, I focused on design and landed on adopting a "Material Design https://material.io/" components library, which made it possible to start developing a clean looking and usable interface. Given how complex the UI will need to be, I think this is an asset, but if anyone has objections, please speak soon. Admittedly, it has a strong Google-y feel to it.

*How to use the prototype:* Upload an ODD file (like this one http://www.tei-c.org/Vault/P5/current/xml/tei/custom/odd/tei_bare.odd). Click browse, then click on the "arrow up" button to upload and the "arrow down" to download the new ODD. These buttons are temporary for testing and the process will be more streamlined eventually. You can also see the result in a screenshot below to get an idea quickly.

*Help wanted:*

*- **Test scenarios**:* ODD is complicated. There may be ways in which elements and modules are added / removed that I might have missed. Please read through this brief list https://github.com/raffazizzi/romajs/wiki/Test-scenarios to see if anything is missing.

*- **Modules & Elements UI**:* I made an attempt at keeping the list of modules and elements tidy, though there is a lot of scrolling involved and I wonder if anyone has an idea of how I could organize this better.

*- **Break it*: if you haven't already, try uploading your (canonicalized) ODD and see if the modules and elements are correctly loaded. Make a few changes and see if the new ODD: a) is preserved as much as possible; b) the new stuff is there.

*Next Steps:* - start working on element operations - start working on a "dashboard" page - start bugging people directly for help

Raff

On Wed, Apr 26, 2017 at 5:46 PM, Scholger, Martina ( martina.scholger@uni-graz.at) wrote:

...

Dear Raff,

I had a look at the current state of your RomaJS development and tested some .odd files. They aren't very sophisticated, so I wasn't able to break it ;-) I would volunteer to help with the development, maybe I could help with the CSS framework? Cool, what you already managed since the F2F!

Best, Martina

-----Ursprüngliche Nachricht----- Von: tei-council-bounces@lists.tei-c.org [mailto:tei-council-bounces@ lists.tei-c.org] Im Auftrag von Raffaele Viglianti Gesendet: Dienstag, 28. März 2017 23:29 An: tei-council@lists.tei-c.org Betreff: [tei-council] RomaJS development update

Dear council members,

I've completed a first phase of development of RomaJS (a placeholder name) and I would like to both give you an update and seek volunteers for the next phase of work. *The prompts for your contributions are highlighted in bold below (bring friends!).*

The code is on GitHub: https://github.com/raffazizzi/romajs

1. Summary of work:

I've have been writing this Redux / React <http://redux.js.org/docs/ basics/UsageWithReact.html> application by focusing on data operations first, user interface second. Briefly, the application is now capable of:

- reading in an ODD file from the web or from disk - reading in a source file (ie p5 subset in JSON format) - add and remove modules - add and remove elements - write an updated ODD to disk (This is actually only mocked for user testing at the moment.) - provide basic UI components for these operations (working towards what's been sketched in the wireframes <https://docs.google.com/presentation/d/ 1sUESuY9pF3DkHoQMJJjrVMV2SPFQYE1YqmGrpA3wrMM/edit> )

2. Tests

Each operation is comprehensively tested. I've aimed at creating a solid testing infrastructure that is at the core of the application development. I have created two wiki pages to help understanding and developing tests:

- a list of test scenarios https://github.com/raffazizzi/romajs/wiki/Test-scenarios - a short guide on how to write tests https://github.com/raffazizzi/romajs/wiki/How-to-write-tests

*Please look at the list of test scenarios: have I not tested something?* You'll see that the list includes different ways of including/excluding modules and elements in ODD. *Have I covered all the mechanisms for doing so? What's missing?* We could discuss this on this email or on the wiki. It would be awesome if then someone besides me would write new tests that result from the discussion!

3. Parsing ODD

In order to avoid using a heavy DOM processor, and to make it possible to include ODD directly in the application state, I've opted to convert ODD to JSON. At first I was using an off the shelf library that served me very well until I had to serialize back to XML and realized that mixed content was all screwy...

So I wrote my own library here: https://github.com/raffazizzi/squash-xml-json The library is quite central to the success of RomaJS and while it has some tests, it needs more extensive testing. *Would anyone like to help test and develop it? Or perhaps know of viable alternatives I've overlooked?*

4. Getting started with the UI

I've created basic UI components to do the operations described above. Here is the current very bare version: https://raffazizzi.github.io/ romajs/ *Please try it out with as many (canonicalized) ODD files that you have lying around. Does it do what you expect? Do you get back XML that matched what you wanted? **Please break it (hopefully it will take a few hits first).*

5. Next steps

I think I may focus more on UI development now (as per wireframes < https://docs.google.com/presentation/d/1sUESuY9pF3DkHoQMJJjrVMV2SPFQY E1YqmGrpA3wrMM/edit>). Getting started with a CSS framework library and nail down general functionality up to the point where we are now. At the same time, I'd like to get started on operations to change elements (basically creating elementSpec[@mode="change"]). *This would be a good time for others to step in the development process: others could start writing operations and tests for changing elements while I focus on UI. Or viceversa. The current module/element operations and tests provide examples of how this all works (and of course I'd be happy to explain stuff).*

6. Finally: decision tree

At the F2F we started talking about a possible "decision tree" as a way into RomaJS. I started a document <https://docs.google.com/document/d/ 1r33QbY7O0HqOHvTxZtOq_-MrYqtIE572YqPEY3JrQr0/edit> with a list of possible questions to the user; James commented on it. *Please comment and add your additions if you can. I would be thrilled if others would want to explore this further as a mind map, etc. so that it's nicely planned out before starting development on a decision tree feature.*

As development gains momentum, I hope to write similar reports to this one at least once monthly.

Raff -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

*- **Test scenarios**:* ODD is complicated. There may be ways in which elements and modules are added / removed that I might have missed. Please read through this brief list https://github.com/raffazizzi/romajs/wiki/Test-scenarios to see if anything is missing.

I don't know how to add comments to or edit a GitHub wiki. (Not much of a wiki if others can't edit it, is it? But it's probably just me. I so rarely use the GitHub interface.) Anyway ... |> can't fix: it would require traversing the ODD again and I'd rather |> keep the redundancy in the ODD (moduleRef/@exclude AND |> elementSpec[@mode='delete']as it doesn't change the ODD at |> compilation. I'm really suspicious of this. While I get that it's a lot of work, it does not seem to me like a minor thing to send an ODD back to the user that has both an <elementSpec mode=delete> and a for the same element. We are going to get *lots* of complaints of the sort "I have an ODD that deletes X; I want X back, so I removed the <elementSpec ident=X mode=delete>, but X is still missing from my schema!". Besides, aren't you going to come across other things that will require traversing the ODD again? (Whatever that means :-)

*- **Modules & Elements UI**:* I made an attempt at keeping the list of modules and elements tidy, though there is a lot of scrolling involved and I wonder if anyone has an idea of how I could organize this better.

Thoughts on the UI: * Much better than anything I would have come up with on my own. Kudos to you. * I hate it; but I think most people will like it. That's because I have trouble using a mouse, but most people prefer to use a mouse. * Two thoughts for improvement - immediate: reduce leading between element names - at some point, perhaps future version: when a particular list is "active" (i.e., when it is the one that gets scrolled), give the user completion -- allow me to type the first few letters of an element to scroll to it, and to select/deselect it by pressing SPACE or RET or some such.

*- **Break it*: if you haven't already, try uploading your (canonicalized) ODD and see if the modules and elements are correctly loaded. Make a few changes and see if the new ODD: a) is preserved as much as possible; b) the new stuff is there.

Worked for me on 1 simple test. But what, pray tell, is a canonicalized ODD?

- start bugging people directly for help

I am eager to help by testing ODDs or writing XSLT, but when it comes to Javascript you would have to get around my 10-foot pole.

Syd, as you figured out, you only need nodejs and npm if you want to develop. The end result is a static site (HTML, CSS, JS) that can be dropped anywhere. If you want to obtain that output to use it offline, you will find it at the gh-pages branch https://github.com/raffazizzi/romajs/tree/gh-pages (I'll updated it every time I report back to council). Also beware that some design assets may be remote for now, so I can't guarantee full off-line use.

Check, thanks. I just successfully cloned, checked out gh-pages, opened the index, and "uploaded" an ODD. (What does "gh" stand for?)

Any GitHub user should be able to edit, so make sure you're logged in. The edit button is on the same line as the wiki page title, far to the right.

Nope, still don't see it. I presume the wiki page title is "Test scenarios", but even if it isn't, I don't see *anything* that would make me think it is an edit button. (Not that it's your job to teach me the GitHub GUI.)

It means having the program visit all of the tree nodes again. You're right that there may be a handful of cases where this is inescapable, but it slows things down, which is not great when you want a responsive UI.

True enough. Would it help to start by storing a trimmed down version of the ODD for fast access? (The way the build process creates p5subset.xml.)

Good idea. I'm keen on making it as accessible as possible. In addition, I plan on creating a search box at the top that would allow the user to filter the module and elements. So typing "pers" would considerably reduce the lists to only show those modules containing elements whose tag name start with "pers".

Oh. I like that. (And someday we might want to be able to search for "model.biblLike" or "att.datable" and see only those elements that are members of that class.) Would be nice to have a "collapse this module right out of the main portion of the interface, 'cause I know I don't want it" capability, too. Another thought is to move the element (but not necessarily module) check boxes to the L of the element name. (Not sure if that's better or not, would want to see it. Advantage is that it allows for consistent whitespace between boxes and name, which the human eye likes.) And (eventually) we would want the name of the module or the gloss of the element as a mouse- over of the module name or element name.

Not sure whether that's accurate terminology, but it's what Oxygen calls resolving external dependencies (usually --exclusively?-- via XInclude). You find it under "Tools" > "Canonicalize..."

Ah! I think then you mean an ODD file in Canonical format. I have never fully understood the point of an exclusive canonicalization, but it has to do with digital signatures. What canonicalization does is listed in [1]. But note that XInclude processing is *not* part of this process. Whether oXygen does XInclude processing during canonicalization depends entirely on whether or not you have the Options > Preferences > XML > XML Parser > Enable XInclude processing checked or not.

I was just discussing this with James: a JavaScript web application will have trouble obtaining external dependencies, even if they're on the web. We may need to rely either on the user to canonicalize their ODD, or on a server-side component (hopefully oxgarage?), though that will still not fix all issues. Basically working with Roma JS will be like sending your ODD to a friend. If you don't make sure all parts are included, your friend won't be able to fix that troublesome schematron and generate a new schema for you.

I have to admit I don't understand *why* Javascript can talk to OxGarage but couldn't talk to the server where I store a snippet of ODD for my main ODD to read. But no matter. As long as there's a clear error message, I don't see a problem. For an example, see [2].

I was thinking of reaching out to you and Lou for looking over the wiki page with the tests and you have. Thanks! Can you think of other ways of including, adding, excluding, removing, etc modules and elements that are not in that list?

Well, you can remove all model classes to which an element belongs, or remove it from each of those classes. (Presuming it is not included directly in some content model somewhere.) But that isn't really removing it, just rendering it useless. Notes ----- [1] See http://www.w3.org/TR/xml-c14n for details, but basically it does the following. * Encode document in UTF-8 * Line breaks normalized to U+000A * Attr values normalized (as if by a validating processor) * Character and parsed entity references are replaced * CDATA sections are replaced with their character content * XML decl & DTD are removed * <duck/> is converted to <duck></duck> * Whitespace outside of the document element and within start and end tags is normalized * Attr value delimiters are set to double straight quotation marks * Special characters in attribute values and character content are replaced by character references * Superfluous namespace declarations are removed from each element * Default attributes are added to each element * Lexicographic order is imposed on the namespace declarations and attributes of each element [2] Something like +--------- |http://www.w3.org/2001/XInclude" prefix="xi"/> |sch:pattern | | I’m sorry, your ODD (“”) uses XInclude, | and RomaJS does not know how to perform XInclusions. Please perform XInclude | processing on your ODD first, and then re-submit it. For hints | on how to perform XInclude processing, see [XINCLUDETUTORIAL]. | | +---------

Syd, and all, thanks for your further comments! Some comments below, and a new mock-up attached. On Thu, Apr 27, 2017 at 5:22 PM, Syd Bauman wrote:

...

Good idea. I'm keen on making it as accessible as possible. In addition, I plan on creating a search box at the top that would allow the user to filter the module and elements. So typing "pers" would considerably reduce the lists to only show those modules containing elements whose tag name start with "pers".

Oh. I like that. (And someday we might want to be able to search for "model.biblLike" or "att.datable" and see only those elements that are members of that class.)

Would be nice to have a "collapse this module right out of the main portion of the interface, 'cause I know I don't want it" capability, too.

I had a good exchange with Lou about the prototype and that made me think that it may be a good idea not to have modules as the primary grouping factor. The attached mock-up shows a possible "unified view" that would list every "object" that has an @ident (elements, classes, datatypes). The list can be filtered by object type, or by searching for an object's @ident. Other buttons (not yet in the mock-up) would allow to sort alphabetically or by module. This approach would make it easy to cherry-pick and would free the user from thinking in terms of modules. Module-level operations will still be possible, e.g. (ex|in)clude a module in full, but somewhat secondary. Any thoughts on this approach?

I have to admit I don't understand *why* Javascript can talk to OxGarage but couldn't talk to the server where I store a snippet of ODD for my main ODD to read. But no matter. As long as there's a clear error message, I don't see a problem. For an example, see [2].

It's because of security issues, since JavaScript is someone else's code that you just got from the internet that just runs on your computer without you even knowing. Someone else may speak more precisely to the reason, but in practice it means that resources from the same domain can be accessed no problem, but resources from other domains cannot be accessed unless their provider made them explicitly accessible. See CORS: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing The other issue I foresee has to do with HTTP v HTTPS protocols. If we put Roma JS on HTTPS (and we should), it will only be able to retrieve other secure resources over HTTPS, nada from HTTP. There are ways to work around this and we'll address them as they emerge. Raff