On 15-10-06 04:31 PM, Lou Burnard wrote:
I think the problem Syd is pointing at is that <listPlace>, <listPerson> etc. are typically thought of as metadata elements, so declaring elements in <text> might point up to them as metadata. But now we have an additional metadata component which can itself apply to bits of the header metadata; so there's a potential need for lots of elements that we usually think of as metadata (<listPlace> etc.) to be able to point to <xenoData>, as well as to be pointed at by e.g. <div>.
I thought the purpose of xenoData was to cordon off non-TEI data? If we're going to start allowing pointers into it, life is going to get complicated.
Not pointers into it: pointers to it. We've already allowed that by making it att.declarable and giving it an @xml:id.
I think this is a genuine issue. What's in att.declaring is largely arbitrary -- I can say that a <ref> is associated with a <listPerson> element, but not that a <persName> is associated with a <person> (at least, not through the declaration mechanism).
I agree that it's a bit hard to see why some elements are declaring (notably ref and ptr): that might quite well be a bug. The way to associate a <persName> with a <person> is of course with a @ref, as you well know, not a @decls: the two mechanisms are different.
With the advent of <xenoData>, if it's widely adopted, I'd expect to see a number of requests for elements to be added to att.declaring, among them many header elements. Hugh's case (<listPlace> with associated GeoJSON in <xenoData>) is a good example.
What would be the practical use of doing such a thing?
To specify that this listPlace is generated from, or parallel to, or the source of, or somehow related to, that piece of e.g. GeoJSON. Seems straightforward to me. I might have three blocks of GeoJSON and three listPlace elements; surely it makes sense to be able to say which goes with which? Cheers, Martin