[MEI-L] physLoc

[Roland, Perry (pdr4h)]

Hi, Andrew,

I agree that MEI can't be a moving target forever, but that doesn't mean it shouldn't ever change.  As you say, a hard-line position at either extreme (between always changing and never changing) isn't useful.  "Compromise" is often the operative word.  I also agree with your statement that *some* backward compatibility is necessary.  And I am attempting to maintain it wherever possible.

Your "modest proposal" was essentially what was agreed upon at the last technical group meeting.  That's why the mei-Bibl customization was placed in the incubator and posted to MEI-L (leading to this discussion).  That is also why I'm currently preparing an "MEI 2013" customization that contains other changes.  And I hope we can discuss that on MEI-L as well.

The tech group did not include the requirement of an accompanying stylesheet for the conversion of existing documents to the proposed modification(s), but did agree that such a thing would be necessary with the adoption of the modification(s) into "core" MEI.  It would be wonderful to be proactive about this, but the reality is that the stylesheet for moving from one version to the next will probably always lag behind the newest release because the changes will be moving targets themselves.  It would be difficult to write a stylesheet for conversion to a new version until that new version is settled.  But, the release of a new version doesn't have to be held up while a conversion stylesheet is authored.

Personally, rather than 2 fairly closely spaced releases next year, I would rather have worked towards just one. In my opinion, two releases that both break existing documents gives the impression that we're breaking things willy-nilly.  Shooting for a single major change in March/April better matches our grant schedule and provides us more time to prepare for the change, say by providing conversion stylesheets. :-)

--
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 Andrew Hankinson [andrew.hankinson at mail.mcgill.ca]
Sent: Friday, December 07, 2012 12:10 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] physLoc

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


_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l