[MEI-L] pointing mechanism

[Kőmíves Zoltán]

Well yes, it is mainly for practical reasons. One of the practicalities is
that if I separate the music content, I don't have to make sure that xml:id
across all the musical text are unique. If XInclude can deal with the
duplicate ids, then it sounds like a good solution...

Z


2014-07-23 16:56 GMT+01:00 Raffaele Viglianti <raffaeleviglianti at gmail.com>:

> Hi Zoltan,
>
> Why is the musical text contained at another location? What do you need to
> model? If it's at another location just for practical /architectural
> reasons, I'd consider using XInclude instead of ptr/ref.
>
> Raff
>
>
> On Wed, Jul 23, 2014 at 11:36 AM, Kőmíves Zoltán <zolaemil at gmail.com>
> wrote:
>
>> Dear MEI-L people!
>>
>> I'm trying to express that the musical text is contained at another
>> location, however neither of music, body, mdiv and score elements allow the
>> pointing attributes, nor they can contain ptr of ref elements. I could rely
>> on referencing from a section element, but I wonder why I cannot do it from
>> higher level ones?
>>
>> Or my question worded in another way: the pointing mechanism provided by
>> ptr, ref and the att.pointing attribute class, from their description in
>> the Guidelines, seem to be very generic. I'd assume if it is generic, it
>> would be allowed everywhere where it is not impractical, but their use seem
>> to be a lot more restricted. Why is that?
>>
>> Thanks a lot
>> Zoltan
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140723/3db1b57f/attachment.html>