Of these two options, I am strongly in favor of #2. For a lot of things, Martin's idea of first consulting with the community makes sense. (Should there be an attribute to let you specify the MIME type of the content? Should it be required if the content is not XML? Should there be a mechanism that lets you link a <xenoData> to a very precise spot in your TEI file -- not that we don't already have at least 2 mechanisms for that -- etc.) But for the simple, obvious, oft-requested cases (e.g., "I want to store some Dublin Core in the TEI Header") we should not release a version of <xenoData> that does not give the user a codified way of differentiating "about source" vs "about this TEI". Why? Because if we do, then users will create data that doesn't say, and their data will be worse off for the lack of it. That is, we should be providing guidance. (Yes, I know that some users will not use @scope even if we do provide a "suggested values include" list, as @scope is optional. But 1. Many, many more people will use @scope if it has a suggested values include list. 2. The fact that some people won't use it is not an argument that we shouldn't give those who want to use it the proper tools to do so. 3. If anything, it's an argument that @scope should be required.) If you don't believe me, let's do a little appeal-to-authority experiment. We're all at or have access to significant institutions. Between now and the F2F let's each go to our institutional metadata librarian and ask "I'm adding some Dublin Core metadata to a bunch of TEI files. Do I need to explicitly indicate whether that DC metadata is about the TEI file or is about the book (or whatever) from which that TEI file was transcribed, or can I get away with just leaving it unsaid?" I'll bet a clean pair of socks the vast majority of 'em say you should be explicit. If the reverse is the case (the vast majority say there is no need to explicitly assert "about TEI file" vs "about source", I'll pipe down. I'm not against adding more values to @scope later, I'm not against considering mechanisms for connecting <xenoData> to particular bits of TEI after release. But I am against our saying "because we don't know what other values should be on the list, we won't even give the world guidance on those values that we know should be on it". So while I *much* prefer we put the bloody @scope back, I don't think we should have qualms about delaying the release of <xenoData>. Those who have been asking for this (all N. American librarians, methinks) have been waiting for over a decade (I first heard this requested at ALLC/ACH in Göteborg, 2004-06), so another 6 months isn't a big deal.
I will go with option 1, as long as we follow it up with a consultation with the community to get a sense of the range of uses they would put it to.