On 07/10/15 00:20, Martin Holmes wrote:
On 15-10-06 04:04 PM, Lou Burnard wrote:
Note ---- [1] For now you'd have to put each set of <place>s that had different metadata in the GeoJSON into its own <div> so said <div> could have an @decls that points to the <xenoData>. That said, can someone explain to me why <listPlace> is in att.declarable but not att.declaring?
I was quite baffled by this question for a while. Declarable elements are provided so that declaring elements like <div> can independently select from a number of possibly relevant chunks of metadata provided together in the header. The mechanism is for fine tuning the standard rule that says "what's in the header applies to everything that the header is attached to". It's not for doing the sorts of things you seem to be considering here, if I understand correctly. Certainly I don't see how a hierarchy of declarability (which you seem to be suggesting) would work.
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.
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?