[tei-council] Fwd: Some more on notatedMusic to the council

[Lou Burnard]

One of the (possible) benefits of coming into a discussion late is that 
the discussion may have boiled down to a few fairly simple issues. So am 
I over simplifying if I say that the issue is just about whether <ptr 
type="embed"> (or some sugared variant thereon) would meet the requirement?

I must say I had thought that the proposal was to make the musicNotation 
element itself such a sugared variant on a pointer. Why won't that work 
any more?



On 29/06/11 08:46, James Cummings wrote:
> On 28/06/11 23:31, Sebastian Rahtz wrote:
>> But let's step back a bit from all this - is the rest of the Council happy
>> with Raffaele's proposed music tag as it stands? if so, then I lose the
>> vote, and let's move on. Only if others share my concern about its content
>> model need we continue the debate.
>
> If an 'embed' or similar element existed then I would be happy
> for this to be part of the content model of notatedMusic to
> include this.  My worry about having it only include this (and
> say<desc>) is that it seems an unnecessary layer when you only
> want to have one child element.  Say we only want a<ptr/>  to
> some file of music representation... Do we really need to do
> notatedMusic/embed(orwhatever)/ptr? rather than just
> notatedMusic/ptr?
>
> I'd propose that we accept the content model as it is with the
> proviso to the music encoding community that it may change
> gettting an 'embed' type element or other modifications based on
> community feedback.  (i.e. that it should be considered
> 'unstable' for purposes of backwards compatibility for awhile.)
> We have no mechanism to indicate such things, but as Raffaele
> mentioned the community is quite small and future changes are
> unlikely to cause too much disruption.
>
> Completely separately to that I think that we should look at a
> semantically-neutral grouping element for embedding multiple
> representations of something with a content model including ptr,
> graphic, binaryObject, desc etc. but that discussion of this
> should be on a FR or another thread.
>
> -James
>