[The build for getting tei_customization into the oXygen framework was not working; when Martin & I fixed it, we found that in order to use the tei_customization.rn[cg] schema in oXygen, you have to turn off the "Check ID/IDREF" preference. This troubles Martin very much. It even bothers me a little, because although the documentation for this schema is pretty clear: | If editing an XML document associated with this schema in oXygen, | you will need to uncheck the Check ID/IDREF preference box. It can | be found in Options > Preferences > XML > XML Parser > RELAX NG. the user who gets to this schema from the oXygen framework does not have trivial access to the documentation.] So, I have figured out what has to be done to the tei_customization.rnc schema to remove the conflicting-ID types. I've done it by hand in a copy, so we can diff them. I have not thought about how we'd go about generating these changes at build time. Changes: 1) Disallow sch:* from <xenoData>, xi:fallback, <egXML>, <content>, and <datatype>. 2) Explicitly list every tei:* element that is to be allowed inside an sch:* element that allows foreign children. While (1) is in principle untenable, it is not really much of a problem in practice. There is no reason a user would normally want any sch:* elements in any of those elements except <egXML>, and there the element can be represented with a different namespace, I suppose. (I.e., bind 'sch:' to "http://purl.oclc.org/NOT/dsdl/schematron/", and then use sch:rule in the <egXML>. Or, if all the elements in the example are Schematron, leave them unprefixed, and let the prose explain that they are from the Schematron namespace.) Number (2) is a bit of a problem in that we don't really know how to predict what TEI elements a user might want inside his or her Schematron. Certainly <gi>, <att>, <val>, and <tag> are important to have, and those are the ones I've listed in my hand-tweaked version. But what about <measure>, <emph>, or <soCalled>? (I'd say yes.) Should multiple tei:p elements be allowed? (I'm inclined against.) How about an entire <TEI>? (Seems completely nuts.) Anyway, grab both http://paramedic.wwp.northeastern.edu/~syd/temp/TEI_Council/tei_customizatio... and http://paramedic.wwp.northeastern.edu/~syd/temp/TEI_Council/tei_customizatio... and diff the two when you have a chance.