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

Tue Aug 20 10:36:28 CEST 2013

One more remark: I can perfectly see the drawback of seeing MEI becoming a
standard if this can make it loose some of its flexibility in its
development. However, I am pretty sure we all aim at seeing MEI becoming as
stable as possible. When developing tools, be they commercial or scholarly,
changes in the specifications create extra work. In a way, making well
organized and versioned releases as we do now is a way of standardizing it.
And we certainly hope to see the frequency of the versions to be as low as
possible. Versioning with a standard is also possible, isn't 'it? So to me,
the question is more to see if we can find a standardization path or
structure that do not create overhead that we can not afford.

Best,
Laurent

On Tue, Aug 20, 2013 at 8:32 AM, Johannes Kepper <kepper at edirom.de> wrote:

> Some more thoughts…
>
>
> We had a proposal on a toolkit for MEI, that would have offered several
> profiles of MEI for specific tasks, conversions between these profiles, and
> other common tasks that would have facilitated usage of MEI significantly.
> The plan was to do this as a group, with almost all projects currently
> developing for MEI being involved. It appears our proposal wasn't spelled
> convincingly enough, so it didn't go through. However, the idea is still
> alive, and we're definitely looking for appropriate tracks to re-submit.
>
> The main difference to the idea of a core set is that we intentionally had
> several such core sets. It would be easy to identify just one core subset
> of MEI that would satisfy the needs of average music software developers.
> It would probably be something like the cmn module, with a reduced header
> and little else. Actually, not much has changed here in the last three
> years. However, such a subset would not satisfy the needs of almost all
> projects currently involved in MEI. It may or may not be appropriate for
> corpus analysis, but even there, I'd say it neglects the potential of other
> MEI modules more appropriate to the purpose.
>
> So yes, such a core set of MEI is likely to increase software support for
> MEI. But at the same time, it doesn't buy us much more than our own
> MusicXML equivalent within the world of MEI. We (as academics) still have
> to (up|down)convert our data into and out of this subset. In essence, there
> is little gain compared to the current situation with MusicXML and the
> converter we provide (please note that Perry is working on the opposite
> direction back into MusicXML right now). But, making such a core subset a
> Standard recognized by some Standards organization will effectively freeze
> development on everything that's inside the Standard. In my daily work, I
> regularly notice areas in MEI that haven't been used much ever since their
> invention, which may benefit from a gentle remodelling. When I said that
> the probable core was stable for some years now, this wasn't completely
> correct. The one big thing we changed significantly was the treatment of
> ossia. Are we really in the position to say that no such case will be found
> in the next few years? Even if so, can we exclude the possibility that
> changes to one of the more distant modules eventually result in changes to
> this core?
>
> So instead of defining and standardizing one core set of MEI, I'm in favor
> of specifying multiple profiles, each for a specific task. Read the word
> profile as nothing more than a best practice recommendation when you want
> to interchange with other applications operating in the same area.
> Actually, the reason for the little amount of code sharing between our
> projects is the fact that we all operate on different profiles already.
>
> I'm very much in favor of providing better / more stable "interfaces" for
> developers. However, I think it is important to clearly communicate the
> fact that MEI is more than just a well-defined format for common use cases
> – it is a framework that offers a whole realm of encoding options, which
> need to be selected and specified in order to distill an actually usable
> format. My point is that by providing a whole set of standards (notice the
> small s) based on / derived from the MEI framework, it seems more likely
> that we as the scholarly community keep control over MEI as a whole. We
> need to find the right tradeoff between widest possible dissemination (also
> in the commercial world) and continued applicability for our scholarly
> needs. No one ever said that this would be easy… (but isn't the fact that
> we're facing this problem already an indication of success?)
>
> Best,
> Johannes
>
>
>
>
>
>
>
>
> Am 19.08.2013 um 23:28 schrieb David Meredith:
>
> > 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>
> > Reply-To: Music Encoding Initiative <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>
> > 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>
> >>  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>
> 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 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>:
> >>>> >
> >>>> >> 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 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> 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
> >>>
> >>> _______________________________________________
> >>> 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
>
>
>
-------------- section suivante --------------
Une pi�ce jointe HTML a �t� nettoy�e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130820/6ac81936/attachment.html>