KH> As for the value of the attribute (whatever name you choose) ... KH> While "source" is well established in the Guidelines for the KH> thing described by <sourceDesc>, "transcription" is not generally KH> used ... "electronic text" is often used, as are "computer file", KH> "electronic file", and "electronic work". So maybe the suggested KH> value of the attribute could be one of the following: KH> * electronicText KH> * computerFile KH> * electronicFile KH> * electronicWork I agree that "transcription" is not ideal, but my complaint with the suggestions above is that they do not differentiate between the source document (which might well be an electronic text, a computer file, or some other electronic work) and the current TEI file. I kinda want "thisTEI", but that's dorky. FC> I still am favorable with adding [xenoData] to att.type class. FC> Instead I do not really like the idea of having a list of FC> suggested value, since the possibilities are quite a lot (for FC> instance one could use xeno to add PREMIS metatada that refine FC> revisionDesc, or texhincal metadata for images of manuscript), FC> and many other thing we can not think of now. I don't think any one is suggesting that there be a "closed" value list; I was suggesting (and I think there is some support for) a "semi" value list of "suggested values include". There really is no point in your project using "Source", mine using "src", and Lou using "original" to mean the same thing. (And, while I don't speak PREMIS well, it would certainly be "thisTEI" or whatever if it refined <revisionDesc>, no?) FC> 1) probably it would be good to have a special attribute to state the FC> type of metadata vocabulary used ... .. LB> How about @scheme (for the format of the metadata) I see no need for such an attribute, as I don't see what advantage it brings. You (the programmer who has just been handed a TEI document) find out what xeno-data schemes were used in <xenoData> by issuing distinct-values( /TEI/teiHeader/xenoData//*/namespace-uri(.) ) or some such. It's mildly more complicated, but much more reliable, than /TEI/teiHeader/xenoData/@scheme Having @scheme just allows a mis-match. FC> 2) we could suggest the usage of @corresp or @sameAs tu say the FC> fqact thata a xeno element compkly one of the standard TEI FC> metadata elements I don't like this idea. I don't think we need a method to say "this metadata duplicates the information found in <whatEver>". If we decide we want to, @sameAs is not tenable, it has the wrong semantics. @corresp isn't crazy, but I shy away from it anyway. Not sure I can explain why at the moment. (Which means I could probably be talked into it. :-) FC> 3) a good thing is to add to xeno is an attribute to assert that a FC> set of xeno metadata apply to a specific part of the TEI file ... .. MH> How about adding <xenoData> to att.pointing? Then it can be MH> linked very precisely to the location(s) in the rest of the file MH> to which the metadata applies The TEI already has a mechanism for indicating to which portions of a TEI document certain bits of metadata apply. It makes use of the @decls attribute in the document, which points to the applicable bit of metadata. See 15.3.2. (And note that <xenoData> is already a member of att.declarable.) FC> 4) someone would like to point at xeno residing in an external FC> file. Not sure exactly what you mean here, Fabio. If someone wanted to point to external metadata, they would have no reason to wrap said metadata into a tei:xenoData element. So I don't think that's what you have in mind. I think you have the case where I want to explicitly say "my MODS record for this file is over there". Not a bad idea, really. I'm inclined to say either A. we should not worry ourselves with this (until it becomes a feature request) B. allow tei:ptr as a child of <xenoData> as you suggest C. add @target to <xenoData> If we go for C, I'm inclined to have @target be used instead of content (i.e., a given <xenoData> may have either @target or child::*, not both), but as long as we define what it means if both are present, allowing both is OK. (Possibilities include: * use @target, ignore children * use children, ignore @target * use both * look for @target, use if found; if not found, use children at least, maybe others. :-) JC> would meet the test for membership of att.typed. .. MH> I was actually arguing for membership of att.typed .. SB> we are (deliberately) making the same mistake TEI made with @type SB> of <name> and friends .. KH> same concern about using @type. .. FC> I still am favorable with adding [xenoData] to att.type class. .. LB> Please please let's not use @type for this ! I'm with Kevin and Lou that @type is not a good way to differentiate "the metadata herein describes the source" from "the metadata herein describes the TEI file". But that doesn't mean <xenoData> shouldn't be in att.typed, anyway, as it is repeatable and categorizable. Thoughts? LB> How about ... @scope (for its err scope, i.e. what it's about) .. MH> We already have four completely different @scope attributes; MH> please let's not add a fifth. .. LB> Well, I am not so sure these four are all semantically LB> "completely different" -- they all say something about the extent LB> to which the annotation concerned is universally (or not) LB> applicable. Which is more or less what we want here, surley? But LB> by all means let's have anothjer suggestion. I'm with Lou, here. If we can come up with something better, sure -- but @scope is pretty close to spot on. Do people dislike my original suggestion "@describes"? LB> I also think that any typology of closed values we might propose will LB> just look silly. While perhaps true for @type (and I'm not convinced), I disagree completely with respect to @scope or @describes or whatever we call it. As I said above, we definitely want a "suggested values include" list here, especially for the two most common cases, "source" and "thisTEI" (or whatever).