On 15-10-06 02:03 PM, Syd Bauman wrote:
<xenoData> already does not permit any elements from the TEI namespace. (It also does not permit the teix:egXML element.)
This is because macro.anyXML can *not* include elements from TEI.
Of course you're right. Sorry, not thinking. Cheers, Martin
As currently conceived, we would *never*, under any circumstances, permit a tei:desc as a child of <xenoData> to describe its purpose/target/function in vanilla TEI. (We can't stop a user from customizing to do that, of course.)
Thus there is no ambiguity here.
But that utter lack of ambiguity also allows us to change our conception, and to permit model.labelLike as a 1st child of <xenoData> for the very purpose of indicating or describing its purpose/target/function.
I don't think I like it. It adds complexity where there may be no need for it -- here I think it may make sense to wait and see if there is any demand. I suspect @type and @subtype will be enough. But I am certainly willing and interested to hear other points of view.
I think given what <xenoData> is really for -- here be non-TEI -- it shouldn't have TEI children. You'll tell me that anyXML can include TEI perfectly well, which is true, but I don't think that's the same thing as adding something that's specifically TEI to its content model. How would we distinguish a <desc> that's added as a child of <xenoData> to describe its purpose/target/function from a <desc> that's "part of" the xenoData itself, but happens to be TEI? I don't like the ambiguity there.