[MEI-L] physLoc

[Andrew Hankinson]

I admit that I'm at a disadvantage, since I couldn't make it to the last developers call, but I feel I must push the need for *some* backwards compatibility fairly strongly. Whether that's a first-or-second digit release is somewhat irrelevant, since breaking compatibility is a pain, no matter what we call it. I don't think breaking compatibility whenever we need to form "a more perfect spec" is a sustainable way forward.

This could mean something like ensuring we have a stylesheet in place when a compatibility-breaking version is released to transform older versions to newer versions, but I feel very strongly that if we're to gain some traction we cannot always present a moving target to the folks that are implementing MEI.

Here's a modest proposal:

 -- New compatibility-breaking changes are placed in an ODD customization somewhere (perhaps the incubator).
 -- Those who are seeking to have those customizations rolled into "core" must also supply an XSLT to transform documents in the current version to their proposed version.

In my opinion, MusicXML goes too far in maintaining backwards-compatiblity at the expense of more sane or robust methods of representation, but I'd not like to see us adopt an opposite, but just as absolute, practice.

-Andrew

On 2012-12-07, at 11:02 AM, "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>
 wrote:

> The die has been cast -- The releases scheduled for January and March 2013 will break compatibility with MEI 2012, the first (2.0.1) in order to correct of errors and omissions in MEI 2012 and the second (2.1.0) to introduce new features.  Let's move on.
> 
> --
> p.
> 
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> ________________________________________
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de]
> Sent: Friday, December 07, 2012 10:39 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] physLoc
> 
> If I remember correctly, a second-digit change is allowed to break compatibility. Benjamin's report from our last meeting (mail from September 15th) reads:
> 
>> The final conclusion was first digit (major changes: e.g. anything that introduces new models / new structures / new version of ODD), second digit (middling changes: more significant, probably breaking [compatibility]) and third digit (minor changes: mostly not breaking [compatibility]) and not restricting this to either specifications or guidelines.
> 
> One could argue that the whole release, which will include not only the bibl customization, but also the FRB model, justifies a new first-digit release number. But we had that discussion already, and we decided to call it a 2.1.0 during the tech team meeting. Given the amount of time we already invested, do we really want to re-open that can of worms? I'm not against it, I just want to be sure it's necessary…
> 
> Best,
> Johannes
> 
> 
> 
> Am 07.12.2012 um 15:25 schrieb Axel Teich Geertinger <atge at kb.dk>:
> 
>> True. But as far as I can see there are changes in the bibl customization breaking compatibility already, such as replacing <geogName> with <pubPlace> in <pubStmt>. That may be a mistake, though.
>> 
>> /axel
>> 
>> 
>> 
>> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Andrew Hankinson
>> Sendt: 7. december 2012 15:09
>> Til: Music Encoding Initiative
>> Emne: Re: [MEI-L] physLoc
>> 
>> 
>> 
>> Backwards compatibility... well, compatibility to MEI 2010 was severely broken already with v. 2.0.0, and I doubt anyone has adapted the 2012 <source> encoding yet. I don't think that should be the reason for not changing anything.
>> 
>> I have no "horse in the race" for the source encoding problem, but I would like to jump in on this point. If we're breaking compatibility, then this is a 3.0.0 issue.
>> 
>> -Andrew
>> _______________________________________________
>> 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