[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.
-James
--
Dr James Cummings, InfoDev,
Computing Services, University of Oxford
More information about the tei-council
mailing list