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

James Cummings James.Cummings at oucs.ox.ac.uk
Wed Jun 29 05:42:45 EDT 2011

On 29/06/11 10:12, Sebastian Rahtz wrote:
> On 29 Jun 2011, at 10:03, James Cummings wrote:
>> On 29/06/11 09:51, Sebastian Rahtz wrote:
>>> no, you're misunderstanding.<embed>   is _instead_ of<ptr>
>> I don't like that.  If I have one ptr why should I have to do
>> notatedMusic/embed/ptr?
> you dont…

Ok, I'm confused then. If I have some notated music and want to 
put in a pointer to a version of it, how would I be marking this up?

> why this obsession with using<ptr>  i wonder

*shrug* do you have another element we should be using to point 
to things? I suppose one could arguably use <ref> but <ptr> seems 
cleaner to me.

> ah, you fall into the Martin H school of thought.
> so you think<graphic url="foo.jpg"/>  and<ptr target="foo.jpg"/>
> are more or less interchangeable, the former is just syntactic
> sugar, with an implied @rend='transclude'?

Sort of, because that is what I understand from my reading of the 
guidelines. Except that if I saw <ptr target="foo.jpg"/> I would 
assume that it was expressly not having an abusive 
@rend="transclude".  But just because I see a <graphic/> (which 
indicates an inline graphic) or a <ptr/> doesn't mean I have to 
process it by going and getting and transcluding that graphic 
image (or whatever) into the output of my choice.  All processing 
is free to ignore the semantics of the input document however so 
it may wish.  I recognise that normal processing of <graphic/> is 
to transclude a graphic image, and the normal processing of 
<ptr/> might be to create a link (unless there is an abusive 
@rend='transclude' or similar). But the point is that those are 
all processing decisions and the creation of the semantics of the 
element shouldn't be based on those.  I haven't seen a good 
argument for not wanting to have a semantically neutral pointing 
element inside of notatedMusic, <ptr/> is currently the 
semantically neutral pointing element that we have.

> perhaps I am too close to the realist coalface, but I want
> TEI documents coming at me whose rendering semantics
> into web pages is pretty obvious.

I think deciding element semantics based on processing them into 
web pages is the wrong way to go about it.

> Jumping from hyperlink
> to embedded graphic on the basis of an arbitrary @rend, or
> special-cased based on name of parent element, seems
> like old-skool TEI to me :-}

Who said that <ptr/> produces a hyperlink? That is a processing 
assumption, it records a pointer to another location, not what 
you should do about it.  <ptr/> and <graphic/> are both just 
pointing at objects. <graphic/> because of its meaning of 
indicating the location of an inline graphic, illustration, or 
figure is almost always processed by transclusion of that graphic 
into the output. (But it doesn't have to be and its definition 
does not imply that you will do this.) One could equally be 
transcluding every <ptr/> one finds.

But I think this is entirely off the point of whether 
notatedMusic as a proposal should be implemented.  I would say 
that we implement it, as any future developments which would 
change this (with a new embed element) are easily transformable 
with a bit of XSLT.


Dr James Cummings, InfoDev,
Computing Services, University of Oxford

More information about the tei-council mailing list