Re: Requirements Matrix and Architectural Proposals

Hi all,

Great to see you all yesterday. Nice to see that you are all real 
people! :-)

I'd also like to thank Joe for his first draft of the Architectural 
Proposals. There are some really important insights there. However, I 
completely agree with Zoltan, that we need to discuss the architecture 
without mentioning specific technologies (SVG, MusicXML, CSS etc.)

I was only able to finish reading Joe's doc just before the meeting, so 
there wasn't really time for it to sink in, or for me to prepare a 
considered reply.

Here's what's going through my mind this morning:

/I have a working prototype that is an instance of such an architecture./
Here's a description, leaving out the specific technologies:

There is an authoring application (AA), that creates an instance of a 
score (/INSTANCE/).
The /INSTANCE/ is parsed by an application (PA) that does something with 
the contained data.
AA makes a contract (/CONTRACT/) with PA telling it how the data can be 
parsed.

That's all.

Here's how my prototype fits this model (the code is all open-source on 
GitHub - see [1]):
AA is my Assistant Composer, which is part of  Moritz (happens to be 
written in C#, and runs offline inside Visual Studio).
Each INSTANCE that Moritz creates is a score written in standard SVG, 
extended to contain MIDI information.
The Assistant Composer creates its output according to the CONTRACT [2], 
and (in every INSTANCE) includes an xlink: to a file that tells PA's 
Developer how the file is organised.
PA is my Assistant Performer web application. There is a stable, working 
version at [3].

The CONTRACT Moritz uses isn't machine readable,  but that doesn't 
really matter because the Assistant Performer doesn't have to parse the 
file. All that is really necessary is that the Assistant Performer's 
/Developer/ can find out how the file is structured, so as to be able to 
program his app correctly.
Unfortunately I don't know how to write a machine readable schema that 
describes extensions to SVG. Maybe someone here does? If it were machine 
readable, then software could be written that could check if the 
INSTANCE really conforms to the CONTRACT.

More about the CONTRACT:
This just contains the formal names of the objects in the file, and how 
they are nested. The names are supposed to be self-explanatory. My Svg 
Score Extensions [1] document provides some comments too.
Common Western Music Notation defines things like "system", "staff", 
"voice", "chord" etc.
Non-Western musics would define things with other names, that nest in 
their own ways.

I'm not sure that I really understand Zoltan's profiles, but I could 
well imagine them describing different levels of implementation of CMN, 
which would be expressed in different CONTRACTs. For example, the 
parsing application should only look for grace notes if they are 
actually included in the CONTRACT. I imagine that some parsing 
applications might need to be told which notes are grace notes, in order 
to do something special with them. My apps dont use grace notes...

Apropos /Separation of responsibility/. Note that the CONTRACT contains 
no units of measurement. No pixels, no milliseconds. Those are only 
included in the INSTANCEs.
And the parsing application knows when it is reading temporal info 
(milliseconds), and when it is reading spatial info (often pixels).

All the best,
James
[1] https://github.com/notator
[2] http://james-ingram-act-two.de/open-source/svgScoreExtensions.html
[3] 
http://james-ingram-act-two.de/open-source/assistantPerformer/assistantPerformer.html