Thanks Michael, you made it clear I needed to think a bit more comprehensively about what I put into my question. My apologies for that; I left out a key factor in my question.

I had thought about the solution you mentioned, and the possibility of creating an automated dev tool (presumably xslt) that would run through the schema and insert a local element declaration for the IF inside each element, mimicking the content model of the parent, such that I could run it whenever doing mods to the schema. The showstopper, as far as I know, was that the IF element is in a different namespace from the various elements of which it is a child. These IFs are used for a specific purpose during certain "phases" of XSLT that we run instance files through, and consequently they are defined in a specific namespace with other elements used for related types of parsing. As far as I could figure out, though I could be wrong, there is no way to create a local definition for an element in a different namespace from it's parent; is that right?

I know Im creating a seriously constrained problem, but that's why we've ignored it for so long and left in this undesirable allowance of the whole "kitchen sink" being insertable within these IF elements. It's a big enough issue that I've considered changing the namespaces, but that would be a backwards-incompatible change that would be unacceptable to all our clients with deployed systems. It would be nice to phase the namespace out, but we'd have to double-up on the IF elements allowed and probably confuse clients.

--

Regards,

steve...

--

Steve Batides

MOLTEK Inc.

mobile: 1-727-505-1473

vmail: 1-877-650-8479 x1002

batides@moltek.net

www.moltek.com

**THE CONTENT OF THIS EMAIL IS MOLTEK PROPRIETARY**

DISCLAIMER

Encryption and Viruses: This e-mail and any attachments may not have not been encrypted and therefore they may be liable to be compromised. Viruses and compromises of security are inherent risks in relation to e-mail and consequently it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Confidentiality Notice: The information contained within this is confidential and is intended for the named recipients only. If you are not one of the intended recipients as indicated in the TO, CC and BCC fields, please return it to this firm by e-mail quoting the name of the sender and the addressee. Please then delete it from your system.