[tei-council] notated music

James Cummings James.Cummings at oucs.ox.ac.uk
Tue Jul 5 05:30:39 EDT 2011


On 05/07/11 10:16, Laurent Romary wrote:
> Hi council,
> I'm taking up on this thread to basically come to a similar conclusion as James. We have a duty to move forward with the creation of this element, probably letting the discussion of a more generic element to another ticket.
> I also like the status='reviewed' (even more explicit than 'unstable', which is somehow frightening to read).

The point is to be frightening. If you are frightened off by it, 
then you probably aren't the kind of user who should be using it 
(for the first 6months or until changed to the default 'stable'). 
  @status has a closed value list so it will have to be 
'unstable'. 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.identified.html

> So:
> - I suggest to have show of hands on this proposal
> - expect a volunteer to file in a ticket for a more generic option

And can I suggest that we also ask for volunteers to:
a) Edit the prose to Guidelines style and put into the figures 
chapter
b) Double-check the elementSpec

I'm happy to do both of these, but thought that others might be 
interested in practicing this sort of thing.

-James


> Laurent
>
> Le 5 juil. 2011 à 11:10, James Cummings a écrit :
>
>> On 04/07/11 21:08, Sebastian Rahtz wrote:
>>> Well, in general I'd agree, but this has been hanging around a long time
>>> and discommoding the MEI folks. It was discussed at the last
>>> council meeting, I understand?
>>
>> In the minutes for the meeting:
>>
>> "We agreed that an appropriate name for the proposed container
>> element would be<notatedMusic>  and requested the Music SIG to
>> continue their excellent work by providing a preliminary ODD for
>> the new element. This is now available in the SVN repository,
>> along with a sample ODD embedding it; see further
>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/notatedMusic/
>> )"
>>
>> http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml#body.1_div.1_div.1_div.4
>>
>> They provided the ODD within a few hours of being told that we
>> approved the element and just wanted them to produce an ODD for
>> us to tidy up and include in the Guidelines. While I think us
>> quibbling about the definition of that ODD is entirely
>> appropriate, I believe that we had in substance agreed to the
>> element and were asking them to do some of the work of creating
>> the ODD and prose text which we would refine before putting into
>> the Guidelines.
>>
>> Stuart says:
>>> My reservation to this is that music is not the only content
>> that can
>>> appear in text in this manner and by crafting a solution to
>> fit music we
>>> may be embbedding assumptions about music rather than
>> assumptions about
>>> text.
>>
>> Sure, and that is the reason for the proposed general purpose
>> container element. notatedMusic is just a special case of this.
>>
>>> * graphs in scientific works, which typically have both
>> parallel tabular
>>> and graphical representation and deep-linking into the systems
>> which
>>> generated the experimental data.
>>
>> We have a whole module and chapter for graphs, networks and
>> trees. It is woefully underused and I'm sure that there are
>> possible revisions to it. But otherwise I'd view graphs as I
>> think you mean them as usually expressed as figures. Thus a
>> general purpose containing element inside figure would suit this
>> use-case perfectly.
>>
>>> * maps with embedded locators such as
>>>
>> https://secure.wikimedia.org/wikipedia/en/wiki/File:EU-United_Kingdom.svg
>> which
>>> are print-based half-way point between traditional maps and
>> google maps.
>>
>> I'm less sure about the right solution to that (other than
>> embedding the SVG) but would suspect it involved figure again.
>>
>>> Having said all that, I do support getting a solution to these
>> issues.
>>
>> I think these are all fair points and justifications for the
>> general purpose element. I don't think it stops us implementing
>> the element as requested and then take feedback from the music
>> encoding community and others as to whether any changes are
>> necessary.   We have a value for @status on things like
>> elementSpec of deprecated, unstable, changed, stable.
>>
>> I would propose that notatedMusic be created (basically as
>> specified) but with a @status of 'unstable' until we create the
>> general purpose element which it is a syntatic sugar version.
>> The whole point of that value of @status was to stop development
>> blockages and instead flag that  "the item is new and still under
>> review". (Really it might be good practice to have any new
>> elements listed as such for one 6-month iteration if we are
>> continuing with biannual releases.)
>>
>> -James
>>
>> --
>> Dr James Cummings, InfoDev,
>> Computing Services, University of Oxford
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>
> Laurent Romary
> INRIA&  HUB-IDSL
> laurent.romary at inria.fr
>
>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford


More information about the tei-council mailing list