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

Mon Aug 19 23:28:56 CEST 2013

Some thoughts in response to Andrew's wise words.

1. I don't see why customizability and standardization are mutually exclusive. I would say that there need to be standardized ways of customizing the language and some relatively stable core subset of the language to allow for interchange and interoperability.

2. I agree that MEI should be developed independently of any particular software clients. However, I think (at least a part of) it should be standardized and stable enough to allow for large-scale information interchange and interoperability, so that A's software can read (at least some core subset of) all those encodings that B has worked so hard to produce; and so that B can use A's software to process his encodings. Writing converters to and from MEI helps, but if I have to convert that rich MEI file into some lesser format like MusicXML, kern or MIDI before I can use it, then I lose much of the value of having the information in MEI in the first place. We need powerful software the fully supports MEI and this requires MEI to have a certain guaranteed level of definition and stability.

3. MEI is an XML language. This means it is an information storage and interchange format, not a data-structure. Any reasonably complex piece of application software will read in an MEI file and then represent it internally in some data structure designed specifically for the purpose in hand, that may well bear little resemblance to how the information was stored in the original MEI file. The important thing is that MEI is powerful enough to represent/encode all the information and knowledge about a musical object that users need (or may need). I believe MEI is unique in that it has been developed by people who are extremely knowledgeable about and sensitive to the semantics of music notation of a wide variety of types. This means that it is capable of encoding/representing knowledge and information about music notation that no other format/language can.

4. I don't think anyone can reasonably disagree with the claim that MEI has (relatively) little software support. So far, we have a small number of groups heroically developing software for their own purposes and (relatively) only modest re-use even between these groups. Compared to, say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has relatively little software support. I believe that if a core subset of the MEI specification were managed as a well-recognized stable standard, then it would attract much more interest from software developers. That said, I strongly agree that the definition and development of MEI should remain firmly in the hands of the academics who use it and NOT be transferred to any commercial enterprises.

5. Of course, the maintenance and development of MEI does not have to be done by means of  an official standardization route such as a W3C Recommendation. However, if MEI does not achieve the status of at least a fairly high-profile *de facto* standard, then I'm concerned that it will never achieve the wide-spread use that I believe it deserves.

Incidentally, there do not currently seem to be any W3C working groups or acknowledged member submissions on music notation. Shouldn't we see this as an opportunity for establishing MEI as the standard for representing music notation (of all types) on the web?

Cheers,
Dave

From: Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>>
Reply-To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>>
Date: Monday, 19 August 2013 21:51
To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>>
Subject: Re: [MEI-L] Standards (was: File extensions)

I'm just full of opinions today… :)

I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format.

MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case).

So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client.

When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software.

So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions.

To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl.

The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1)

On the other hand, RFC 6838 says this about Vendor registration:

"The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree.

A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it."

http://tools.ietf.org/html/rfc6838#page-6

The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want.

So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree.

-Andrew

On 2013-08-19, at 3:45 PM, Raffaele Viglianti <raffaeleviglianti at gmail.com<mailto:raffaeleviglianti at gmail.com>>
 wrote:

I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations.

I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms.

I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format.

Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application.

Raf

On Mon, Aug 19, 2013 at 7:26 AM, David Meredith <dave at create.aau.dk<mailto: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<mailto:kepper at edirom.de>> wrote:

>two cents from someone who's completely in the darkŠ
>
>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<mailto: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<mailto:mei-l-bounces at lists.uni-paderborn.de>
>>[mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] på vegne af Andrew Hankinson
>>[andrew.hankinson at mail.mcgill.ca<mailto: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 modulesŠ) 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 XMLŠ)
>>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<mailto: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<mailto:mei-l-bounces at lists.uni-paderborn.de>
>>>[mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] på vegne af Andrew
>>>Hankinson [andrew.hankinson at mail.mcgill.ca<mailto: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><mailto: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><mailto: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><mailto: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-paderborn.de><mailto:mei-l-bounces at lists.uni-pad<mailto:mei-l-bounces at lists.uni-pad>
>>>>erborn.de<http://erborn.de/>>
>>>>[mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de><mailto:mei-l-bounces at lists.uni-pa<mailto:mei-l-bounces at lists.uni-pa>
>>>>derborn.de<http://derborn.de/>>] på vegne af Andrew Hankinson
>>>>[andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca><mailto: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><mailto: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><tel: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:virginia.edu at lists.uni-paderborn.de><mailto:virgini<mailto:virgini>
>>>>>a.edu at lists.uni-paderborn.de<mailto:a.edu at lists.uni-paderborn.de>>
>>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de<mailto:virginia.edu at lists.uni-paderborn.de><mailto:virgin<mailto:virgin>
>>>>>ia.edu at lists.uni-paderborn.de<mailto:ia.edu at lists.uni-paderborn.de>>] on behalf of Sigfrid Lundberg
>>>>>[slu at kb.dk<mailto:slu at kb.dk><mailto: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-paderborn.de><mailto:mei-l-bounces at lists.uni-pa<mailto:mei-l-bounces at lists.uni-pa>
>>>>>derborn.de<http://derborn.de/>>
>>>>>[mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de><mailto:mei-l-bounces at lists.uni-p<mailto:mei-l-bounces at lists.uni-p>
>>>>>aderborn.de<http://aderborn.de/>>] på vegne af Roland, Perry (pdr4h)
>>>>>[pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu><mailto: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><tel: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-paderborn.de><mailto:mei-l-bounces at lists.uni-pa<mailto:mei-l-bounces at lists.uni-pa>
>>>>>derborn.de<http://derborn.de/>>
>>>>>[mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de><mailto:mei-l-bounces at lists.uni-p<mailto:mei-l-bounces at lists.uni-p>
>>>>>aderborn.de<http://aderborn.de/>>] on behalf of Sigfrid Lundberg
>>>>>[slu at kb.dk<mailto:slu at kb.dk><mailto: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-paderborn.de><mailto:mei-l-bounces at lists.uni-pa<mailto:mei-l-bounces at lists.uni-pa>
>>>>>derborn.de<http://derborn.de/>>
>>>>>[mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de><mailto:mei-l-bounces at lists.uni-p<mailto:mei-l-bounces at lists.uni-p>
>>>>>aderborn.de<http://aderborn.de/>>] på vegne af Andrew Hankinson
>>>>>[andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca><mailto:andrew.hankinson at mail.mcgill.c<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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130819/b93accce/attachment.html>