How to define an 'any element' with mandatory attributes - xsd

Question

I have an XML which can have any element such as:
<AnyElements>
<Any1 id="any1" />
<Any2 id="any2" />
...
</AnyElements>
But id attribute is mandatory.
How can i define such a xsd?
<xs:element name="AnyElements" type="AnyRootType" />
<xs:complexType name="AnyRootType">
<xs:sequence>
<xs:any type="AnyChildType" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AnyChildType">
<xs:attribute ref="id" use="required"/>
</xs:complexType>
<xs:attribute name="id" type="xs:string"/>

Answer 1

It all depends on how you're going to define the processing model. Here are some things you need to consider first.
An any particle can't be constrained with a type. It comes with an attribute named processContents that could be skip, lax, and the default, strict. Once you understand exactly what it means, then going with skip simply means that you will not be able to enforce your mandatory attribute - the processor will do just that, "skip". If you set it lax, then it will process it only if the XSD describing the content is actually available, otherwise it'll skip; The third option strict, requires the XSD describing this extra content to be available - period.
So the any particle can be made to work only if the XSD describing the "any" is available during validation. The option I have in mind is kind of limiting, but it has the advantage of being the closest to the "spirit" of an any in that it wouldn't have to derive from a particular base type, or reference some atttributes; for this, a key constraint similar to would approximate your requirement:
<xsd:key name="ofid">
<xsd:selector xpath="*"/>
<xsd:field xpath="#id"/>
</xsd:key>
In effect, the key makes the attribute required. The downside may be that each value must be unique, too. Maybe with an attribute named id , it is expected; if instead you wish to apply the pattern to something such as age, then it wouldn't work.
If you decide that having XSDs available at runtime is acceptable, then other alternatives may include use of abstract elements or elements with abstract types. The good thing is that it'll bring a more disciplined approach (you'll set the constraints clearly right from the beginning), and without placing uniqueness of values constraints. The downside could be that it creates coupling to another XSD which describes the "contract" - your mandatory attributes.
UPDATE: As per your comment, below is an alternative based on substitution groups. I tried to keep as much as possible your old XSD components names.
Contract.xsd: This has the components of your contract. It basically describes the head of your substitution group; it indicates the need for an id attribute.
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="AnyChildType" abstract="true">
<xsd:attribute name="id" use="required"/>
</xsd:complexType>
<xsd:element name="AnyElement" abstract="true" type="AnyChildType"/>
</xsd:schema>
GenericInstance.xsd: It describes the root of your "generic" document. It "integrates" your contract in the context of your defined root element.
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="Contract.xsd"/>
<xsd:element name="AnyElements" type="AnyRootType"/>
<xsd:complexType name="AnyRootType">
<xsd:sequence>
<xsd:element ref="AnyElement" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
SpecificInstance1.xsd: A particular contract.
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="Contract.xsd"/>
<xsd:element name="SomeElement1" substitutionGroup="AnyElement">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="AnyChildType">
<xsd:annotation>
<xsd:documentation>Any content goes.</xsd:documentation>
</xsd:annotation>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
SpecificInstance2.xsd: Another contract (shows a different authoring style).
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="Contract.xsd"/>
<xsd:element name="SomeElement2" substitutionGroup="AnyElement" type="SomeElement2Type"/>
<xsd:complexType name="SomeElement2Type">
<xsd:complexContent>
<xsd:extension base="AnyChildType">
<xsd:annotation>
<xsd:documentation>Any content goes.</xsd:documentation>
</xsd:annotation>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
Visually this is how they're tied together. You can see that the coupling between XSDs is maintained at minimum.
A sample XML, valid in the scope defined by your generic instance, and the specific ones.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Sample XML generated by QTAssistant (http://www.paschidev.com) -->
<AnyElements xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SomeElement1 id="1"/>
<SomeElement2 id="1"/>
</AnyElements>
If you're limited to validate your XML using one XSD only, below would be an XSD just for that:
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="GenericInstance.xsd"/>
<xsd:include schemaLocation="SpecificInstance1.xsd"/>
<xsd:include schemaLocation="SpecificInstance2.xsd"/>
</xsd:schema>
I've tested the above with XSD 1.0 running on .NET; having the ability to run on XSD 1.1 or particular features in other XSD processors would invalidate some of what I've said.