[MEI-L] Standards (was: File extensions)

[Byrd, Donald A.]

It seems clear that there's no consensus in the MEI community on what 
MEI is :-) . Andrew says it "isn't actually an XML schema. I like to 
think that you can express MEI in any formalized structure." That is, 
MEI is more abstract tha a schema, and I agree. On the other hand, Dave 
says "a particular file format [is] basically what MEI is" -- i.e., MEI 
is no more abstract than a schema, perhaps less so, and I agree.

I've been working on a universal representation of time and a paper 
about it, and being forced to think about _representations_ vs. 
_encodings_. The usual distinction is that a representation says what 
information is conveyed; an encoding says how it's conveyed, i.e., what 
bit patterns mean what. Is that the difference between Unicode proper 
(which defines a bunch of code points and principles for assigning new 
ones), and UTF8, UTF16, UTF32, and raw Unicode, hi-endian or 
low-endian, with or without BOMs (each of defines the meaning of 
various patterns of bits)? I don't think so: by assigning code points, 
Unicode proper says how the information is conveyed. The UTFs etc. are 
just rearranging the bits for convenience, e.g., via "transformation 
formats". So maybe hi-endian UTF16 is a _concrete_ encoding, and raw 
Unicode is an _abstract_ encoding. (I just made those terms up, but 
I'll but others have used them before. So be it.)

It seems to me that MEI is, in concept, a representation of music. But 
it's nearly impossible to even _discuss_ representations without using 
encodings! So we generally talk about ODD definitions and XML schemas, 
which I suspect are abstract encodings; what we actually, uh, encode 
music in is a concrete encoding, a.k.a. file format.

I hope this helps, but I'm afraid it'll cause more confusion. If so, 
please forgive me!

--Don



On Mon, 19 Aug 2013 11:26:48 +0000, David Meredith <dave at create.aau.dk> wrote:

> Hi all,
>
> Tomorrow, the "strategy" committee is having its first virtual meeting to
> discuss possible ways in which MEI can be managed in the future.
>
> I will be (tentatively) suggesting that we think about managing it as a
> W3C working group. And I have in my diary to prepare a short presentation
> this afternoon about this. (Sychronicity? :) )
>
> My view is that MEI's volatile and diffuse definition and development is
> *THE* main reason why there has so far been so little interest in
> developing software to support it. Before developing software to support a
> particular file format (let's face it, that's basically what MEI is), a
> software developer needs
>
> 1. a clear definition of what the format is;
> 2. reasonable confidence that his/her software isn't going to become
> obsolete the next time the format's definition is revised; and
> 3. a good idea of how often the format's definition is going to be
> changed, so that they can plan new versions of the software that supports
> it.
>
> These can best be achieved by establishing MEI as a *standard*, with a
> properly published and managed definition and properly established
> processes for developing this definition to accommodate users' changing
> needs while keeping volatility and backwards incompatibility to a minimum
> so that developers aren't scared off.
>
> I'm not completely sure that the W3C route is necessarily the best one,
> but clearly we want some form of standardisation framework that is:
>
> 1. relatively low-ceremony: we're all volunteers, so we don't have oceans
> of time and money to spend on keeping MEI alive;
> 2. well-recognized and international so that we maximise the likelihood of
> people wanting to develop software to support MEI.
>
> If anyone else has experience with this kind of process and would like to
> contribute to tomorrow's meeting, please talk to Benjamin about it.
>
> I agree with Johannes that decisions about the definition and development
> of MEI should remain independent of commercial enterprises. MEI should be
> run by and for the academic community. However, I don't see how clarifying
> and stabilizing the definition and development of MEI would be in any
> sense detrimental.
>
> Cheers,
> Dave
>
>
> On 19/08/2013 12:40, "Johannes Kepper" <kepper at edirom.de> wrote:
>
>> two cents from someone who's completely in the darkS
>>
>> I don't like the "vendor" term: To my (non-native english) ears, it
>> sounds a little bit too commercial. It may or may not fit for MusicXML,
>> but it doesn't seem to fit for us. If there are other tracks, we should
>> follow them instead.
>>
>> If (S|s)tandard in the mimetype sense means something completely
>> determined, it's not appropriate for us. We shouldn't restrict our future
>> development by stocking ourselves to one specific version of MEI which
>> may not be changed easily anymore. I wouldn't even do this for a defined
>> subset of MEI (like cmn), as it has the potential to cannibalize the
>> community, weakening support for other, more obscure parts of MEI.
>> However, if (S|s)tandard is meant to be more open, I'm fine with this.
>> For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one
>> mimetype? If so, it seems comparable to our situation.
>>
>>
>> best,
>> jo
>>
>>
>>
>>
>> Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg <slu at kb.dk>:
>>
>>> Sorry for using the word standard.
>>>
>>> Suppose it is better to describe our business as we are dealers in
>>> methodologies for the description of what is known about pieces of
>>> symbolic music.
>>>
>>> As a long term subscriber to the xml-dev list I'm used to worms, which
>>> doesn't mean that I like them, or even eat them.
>>>
>>> Sigfrid
>>>
>>> ________________________________________
>>> Fra: mei-l-bounces at lists.uni-paderborn.de
>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson
>>> [andrew.hankinson at mail.mcgill.ca]
>>> Sendt: 19. august 2013 11:51
>>> Til: Music Encoding Initiative
>>> Emne: Re: [MEI-L] Standards (was: File extensions)
>>>
>>> Oof. That's a can of worms.
>>>
>>> Warning: Lots of opinions to follow.
>>>
>>> If you're creating physical widgets where part A needs to fit with part
>>> B, big-S Standards can be a great thing.
>>>
>>> For a small and loosely-bound community like MEI, a Standard wouldn't
>>> really bring much to the table, and, I think, would actually cause more
>>> harm than good. What do we standardize? The complete ODD file, including
>>> the parts of the ODD file that are mutually exclusive? (see: integration
>>> of both mensural and CMN timing modulesS) The CMN customization? Any
>>> decision to standardize something will likely exclude a significant part
>>> of the community. We can't even come to a consensus about which file
>>> extension to use!
>>>
>>> What MEI brings to the world isn't actually an XML schema. I like to
>>> think that you can express MEI in any formalized structure. XML brings
>>> the ability to validate and impose constraints, but if XML was to be
>>> eclipsed by another structural language (like SGML was eclipsed by XMLS)
>>> then I think that the intellectual structure of MEI could simply be
>>> transplanted to the new system.
>>>
>>> So, in a roundabout answer to your question: No, I don't think we're
>>> creating a Standard. I think we're creating a method, and I think with
>>> time and usage certain parts of this method may emerge to a de-facto
>>> standard, or even, yes, a Standard. But MEI as a whole? I don't think we
>>> should even think of trying to register this as a Standard. There's just
>>> too many moving parts.
>>>
>>> A vendor-specific mime type seems to be the most flexible method. In my
>>> reading about mime type registration, the "x-" prefix was used for
>>> experimental or non-standard use. Since RFC6648, however, this has been
>>> deprecated. Current best practice, as far as I can tell, says that
>>> non-standards-track mime types should be registered under the
>>> vendor-specific or personal (vanity) track. I would be happy to be
>>> corrected, though -- I'm new at this!
>>>
>>> So, application/vnd.mei+xml, or application/vnd.mei+json, or
>>> application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle
>>> [1] --- all of these are possibilities, but trying to go through the
>>> Standardization process for them seems like a lot of work for little,
>>> no, or even negative gain.
>>>
>>> -Andrew
>>>
>>> [1] http://www.candlescript.org/doc/candle-markup-reference.htm
>>>
>>> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg <slu at kb.dk> wrote:
>>>
>>>> I know that, but why do you want it to register it as a vendor
>>>> specific format.
>>>>
>>>> We're creating a standard, arn't we?
>>>>
>>>> Sigge
>>>> ________________________________________
>>>> Fra: mei-l-bounces at lists.uni-paderborn.de
>>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew
>>>> Hankinson [andrew.hankinson at mail.mcgill.ca]
>>>> Sendt: 16. august 2013 23:53
>>>> Til: Music Encoding Initiative
>>>> Emne: Re: [MEI-L] File extensions
>>>>
>>>> Not quite orthogonal. A web server will serve files with the specified
>>>> extension as a given mime-type. It's true that you can write the mime
>>>> type to the header if you're in a web application environment, but by
>>>> registering a mime type we can provide a method for placing MEI files
>>>> on a server, and it opening in a default application on the users'
>>>> machine, for example.
>>>>
>>>> This can be especially useful in a mobile environment, where sometimes
>>>> you have limited control over which application will open a downloaded
>>>> file.
>>>>
>>>> So, in a web context the extension does matter, since (by default) the
>>>> web server will serve files with a given extension with a certain mime
>>>> type. That's the second part of the mime type definition for servers:
>>>> "application/vnd.mei+xml .mei" maps all .mei files to the
>>>> application/vnd.mei+xml mime type.
>>>>
>>>> Using .xml is fine if you want to open it in an XML editor. However,
>>>> if we want to open it in a notation editor (dreaming of the future)
>>>> then it's best if we choose .mei now, and then allow the user to
>>>> specify the application that handles it as needed.
>>>>
>>>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I
>>>> understand, appending vnd. makes the mime type registration process
>>>> much easier, since it doesn't need to go through the standards bodies
>>>> to be approved. The MusicXML mime type uses the vnd. prefix, something
>>>> like "application/vnd.recordare-musicxml+xml" So I thought that we
>>>> might go for the easy registration first. It doesn't preclude later
>>>> registration of a more formal mimetype. But here I will defer to those
>>>> with more experience in the process.
>>>>
>>>> -Andrew
>>>>
>>>>
>>>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti
>>>> <raffaeleviglianti at gmail.com<mailto:raffaeleviglianti at gmail.com>> wrote:
>>>>
>>>>
>>>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson
>>>> <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>
>>>>> wrote:
>>>>
>>>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type
>>>> seems like a big problem.
>>>>
>>>> application/vnd.mei+xml .mei -> Seems like the best solution, yes?
>>>>
>>>> As far as I know mimetype is orthogonal to file extension, so even if
>>>> we secure a mimetype application/mei+xml it won't matter if your file
>>>> has .xml or .mei extension.
>>>>
>>>> I personally don't see an issue with file extension at all. What's the
>>>> problem with using either .mei or .xml? In a web context all that
>>>> matters is the mimetype, in a OS context, using .xml is generally going
>>>> to make things easier, but it's not eventually not a big deal.
>>>>
>>>> Raf
>>>>
>>>>
>>>> (the MEI mime type I give is just an example).
>>>>
>>>> -Andrew
>>>>
>>>>
>>>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg
>>>> <slu at kb.dk<mailto:slu at kb.dk>>
>>>> wrote:
>>>>
>>>>> .txt is a poor choice. Most web servers will deliver that as
>>>>> text/plain which is not what you want. In apache web server there is a
>>>>> file mime-types which connects extensions to mime types, which then
>>>>> interacts with users web clients and plug-ins and helper applications
>>>>>
>>>>> Sigfrid
>>>>> ________________________________________
>>>>> Fra:
>>>>> mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-pad
>>>>> erborn.de>
>>>>> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-pa
>>>>> derborn.de>] på vegne af Andrew Hankinson
>>>>> [andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca
>>>>>> ]
>>>>> Sendt: 15. august 2013 17:23
>>>>> Til: Music Encoding Initiative
>>>>> Emne: Re: [MEI-L] File extensions
>>>>>
>>>>> You can sign me up too.
>>>>>
>>>>> Personally, I like .mei. XML could also be thought of as plain text,
>>>>> so I would argue that we should go with the most specific usage,
>>>>> rather than the most general. We could just go with .txt and be just
>>>>> as correct as .xml.
>>>>>
>>>>> Either way, though, I think this is an appropriate topic for putting
>>>>> some guidance in the Guidelines. I'll volunteer to write it, but I
>>>>> would like some way of getting a consensus.
>>>>>
>>>>> Any ideas? An online poll?
>>>>>
>>>>> -Andrew
>>>>>
>>>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)"
>>>>> <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Sigge,
>>>>>>
>>>>>> Thanks for being so gracious in your acceptance of my effort to
>>>>>> "volunteer" you.
>>>>>>
>>>>>> There's no rush on this.  After Christmas/beginning of 2014 is fine.
>>>>>> I'm sure you'll find willing volunteers to help you write the
>>>>>> proposal.  You can "volunteer" me in return.  :-)
>>>>>>
>>>>>> Anyone who wants to participate, please contact Sigge.  I hear he's
>>>>>> starting a list.  :-)
>>>>>>
>>>>>> Thanks again,
>>>>>>
>>>>>> --
>>>>>> p.
>>>>>>
>>>>>>
>>>>>> __________________________
>>>>>> Perry Roland
>>>>>> Music Library
>>>>>> University of Virginia
>>>>>> P. O. Box 400175
>>>>>> Charlottesville, VA 22904
>>>>>> 434-982-2702<tel:434-982-2702> (w)
>>>>>> pdr4h (at) virginia (dot) edu
>>>>>> ________________________________________
>>>>>> From:
>>>>>> mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de<mailto:virgini
>>>>>> a.edu at lists.uni-paderborn.de>
>>>>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de<mailto:virgin
>>>>>> ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg
>>>>>> [slu at kb.dk<mailto:slu at kb.dk>]
>>>>>> Sent: Thursday, August 15, 2013 10:49 AM
>>>>>> To: Music Encoding Initiative
>>>>>> Subject: Re: [MEI-L] File extensions
>>>>>>
>>>>>> My keyboard is too fast.
>>>>>>
>>>>>> Cannot promise to write it alone and have to discuss it here in
>>>>>> Copenhagen. Not before Christmas, that's for sure
>>>>>>
>>>>>> S
>>>>>> ________________________________________
>>>>>> Fra:
>>>>>> mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-pa
>>>>>> derborn.de>
>>>>>> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-p
>>>>>> aderborn.de>] på vegne af Roland, Perry (pdr4h)
>>>>>> [pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>]
>>>>>> Sendt: 15. august 2013 16:44
>>>>>> Til: Music Encoding Initiative
>>>>>> Emne: Re: [MEI-L] File extensions
>>>>>>
>>>>>> Hi Sigfrid,
>>>>>>
>>>>>> Sounds like we have a volunteer to lead the way to registering an
>>>>>> MEI mimetype.  :-)
>>>>>>
>>>>>> --
>>>>>> p.
>>>>>>
>>>>>>
>>>>>> __________________________
>>>>>> Perry Roland
>>>>>> Music Library
>>>>>> University of Virginia
>>>>>> P. O. Box 400175
>>>>>> Charlottesville, VA 22904
>>>>>> 434-982-2702<tel:434-982-2702> (w)
>>>>>> pdr4h (at) virginia (dot) edu
>>>>>> ________________________________________
>>>>>> From:
>>>>>> mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-pa
>>>>>> derborn.de>
>>>>>> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-p
>>>>>> aderborn.de>] on behalf of Sigfrid Lundberg
>>>>>> [slu at kb.dk<mailto:slu at kb.dk>]
>>>>>> Sent: Thursday, August 15, 2013 10:39 AM
>>>>>> To: Music Encoding Initiative
>>>>>> Subject: Re: [MEI-L] File extensions
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm using .xml as suffix. Don't really care.
>>>>>>
>>>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I
>>>>>> have strong opinions on your "by the way" question. Yes, we should
>>>>>> register a mime type, and it should be application/mei+xml. Since it
>>>>>> is in the application hierarchy it requires an RFC and some
>>>>>> negotiations with IESG and IETF before one get a line in the
>>>>>> appropriate IANA document.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Sigfrid
>>>>>>
>>>>>> ________________________________________
>>>>>> Fra:
>>>>>> mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-pa
>>>>>> derborn.de>
>>>>>> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-p
>>>>>> aderborn.de>] på vegne af Andrew Hankinson
>>>>>> [andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.c
>>>>>> a>]
>>>>>> Sendt: 15. august 2013 16:12
>>>>>> Til: Music Encoding Initiative
>>>>>> Emne: [MEI-L] File extensions
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Is there a common understanding of what the proper file extension
>>>>>> for MEI files should be?
>>>>>>
>>>>>> I've been assuming .mei is the "standard", but a counter-example of
>>>>>> .xml was recently brought to my attention. So, I thought I'd poll the
>>>>>> collected wisdom and see what others were doing. Are you using .xml,
>>>>>> .mei, or some other variation on these?
>>>>>>
>>>>>> -Andrew
>>>>>>
>>>>>> ====
>>>>>> Related:
>>>>>> -- Should we register an actual mimetype? Maybe:
>>>>>> application/vnd.music-encoding+xml ?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>>
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>>
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mei-l mailing list
>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>
>>>>> _______________________________________________
>>>>> mei-l mailing list
>>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>
>>>>
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>
>>>>
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>
>>>
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington