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 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). 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. Cheers, Martin