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
+---------
|