I think Martin is correct about Hugh's examples. Example #1, if it uses @scope, would be scope=source. Example #2, if it uses @scope, would be scope=other. Two caveats: 1) I agree, we *may* find there is demand for further granularization of "other". At which time, we should likely further granularize it. But for now, it is just a suggested values list, encoders can create their own more granular values. 2) Hugh's example #2b is not something I personally would not encode with <xenoData>. I'd just stick the mods:whatever elements in my bibliography. #2a is a bit trickier, because I don't know what the relationship between Hugh's GeoJSON and the <place> element is. But perhaps the place/@source would do, perhaps there is no need for a 1-to-1 mapping between the GeoJSON and the <place>s (in which case <xenoData> with scope=other or no @scope would do), or perhaps there is a need for a closer relationship, in which case you should whatever you would have done before <xenoData> came along, or use the decls mechanism.[1] FC> My position is that we should discuss this with more deeply at FC> the f2f, and abstain from including this att in the release, for FC> the moment. My instinct (which I might be talked out of) is that releasing <xenoData> without @scope is more harmful than not releasing it. That is, I'd prefer to remove <xenoData> from P5 than have it there without a TEI-defined mechanism for distinguishing "about the source" from "about the TEI document". (Although that mechanism need not be @scope.) HC> I'm not sure what it's useful for though. It is useful for differentiating *what* the metadata is *about*. There will be a lot processes that are going to be very happy they don't have to dive into a given <xenoData> because they're looking for metadata about one, not the other. HC> I also think "transcription" is too specific a term. I kinda agree, but none of us were able to come up with a better one. HC> I do think users will want to have ways to characterize the contents HC> of <xenodata>, but @scope is just sort of a guess at what they HC> might need. First, users will probably want to characterize their <xenoData>s, and they have @type (and @subtype) with which to do so. Second @scope is not a guess about that characterization. It is the answer for the obvious need to differentiate metadata about the source from metadata about the TEI file. (For crying out loud, there are plenty of other bits of metadata in the <teiHeader> for which it is clearly spelled out in the Guidelines whether it is about the TEI file or the source document ... why wouldn't we want at least that level of specificity here?) HC> We'd be better off finding out what those needs are HC> before committing to a solution. As alluded to above, I couldn't disagree more. The TEI _Guidelines_ are supposed to provide _guidance_. We know it is often important to know whether a bit of metadata is about the TEI document (as with <fileDesc> or <correspDesc>) or about the source of that TEI document (as with <sourceDesc> or <revisionDesc>). Since we know that, we should provide users a way to say so. To *not* provide that mechanism means that some users will develop their own mechanisms to say so (which will be incompatible with each other) and others simply won't say (which, admittedly, is still the case with the proposed <xenoData>, as we don't have the guts to make it a required attribute). Why let the world devolve into 2 dozen different ways of saying the same thing? 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?