Re: Layout and Application Profiles

To offer my perspective -- I agree with Zoltan that separation of
presentation and semantics, whatever the mechanism, is not enough here.
There is a need to determine the conditions under which a
particular presentation facet  (e.g. pagination, system breaks, measure
numbers etc.) should apply, and how/whether they should be applied.

This is not really a new issue in the world. It is also the case in
ordinary web pages, as evidenced by the "responsive design" techniques now
common in many sites. Responsive design implies that not all stylistic
attributes translate into the same rendering outcomes under all
circumstances (and indeed, sometimes they may not translate into any
rendering outcome at all).

I think that this process amounts to the same thing as identifying what
Zoltan calls a "profile" -- and there is a way of implementing such
profiles that is provided today in HTML/CSS, namely the concept of media
queries:

https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries


I don't know yet that the existing media query constructs will work
entirely for our purposes (with respect to pagination, there are
outstanding problems), but I believe it's a worthwhile thing to explore. A
solution that draws on this pattern will be more harmonious with the rest
of the web.


.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Fri, Jan 22, 2016 at 9:26 AM, Zoltan Komives <
zoltan.komives@tido-music.com> wrote:

> I'd like to respond to L Peter Deutsch's comment in the thread '*Suppress
> the 'non-controlling' attribute in measures*', but starting a new topic
> because the comments I am making concern longer-term discussions than the
> original question.
>
> On Fri, Jan 15, 2016 at 7:39 PM, L Peter Deutsch <aemusic@major2nd.com>
>  wrote:
> > I have seen it argued that MusicXML importers should be free to disregard
> > any and all elements of the input in favor of their own ideas of layout
> and
> > notation, with no approval by (or even indication to) the user.  I have
> > argued, and will continue to argue, vociferously to the contrary, since
> this
> > stance is contrary to all industry practice in my experience.
>
> I think certainty is very important, we all agree on this. However, in
> terms of layout in particular, a dynamic rendering engine cannot possibly
> be expected to respect static layout information intended for other use
> cases.
> Semantic/presentational separation and style sheets may be the answer to
> some of these questions - however they may not answer the question, to what
> extent the placement of visible objects are semantic or a matter of style -
> especially when considering different applications' point of views at the
> same time.
>
> I agree, adding and disregarding elements in an ad-hoc manner is very bad
> practice. However, it might be possible to define a structured way of doing
> so. The ODD customization framework (which is the basis of MEI) allows for
> a structured way of defining application profiles via a strict schema and
> corresponding guidelines.
>
> Background: at Tido, as well as developing a style sheet language that is
> meant to address semantic vs. presentational problem, we are also working
> on an MEI application profile that documents our consumer application's
> input interface. We recognise that our application may have specific
> requirements from the encoding, but by documenting these requirements with
> an ODD schema, we hope to make the task of creating converters into our
> input format relatively easy.
>
> Best
> Zoltan
>
>
>
> www.tido-music.com
>
> Tido Enterprise GmbH (Amtsgericht Leipzig, HRB 29529), Talstrasse 10,
> 04103 Leipzig, Germany. Disclaimer: The information in this e-mail
> including any attachments is confidential and may be legally privileged. If
> you have received this message in error, please contact the sender
> immediately and delete this message and any copies from your computer and
> network. The unauthorized use, distribution, copying or alteration of this
> e-mail and any attachments is strictly forbidden.
>

Received on Wednesday, 27 January 2016 17:14:08 UTC