<xsd:element name="user_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The user_state element enumerates the different groups (identified by name) that a Windows user might belong to. Please refer to the individual elements in the schema for more details about what each represents.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<xsd:element name="user" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The user entity holds a string that represents the name of a particular user. In Windows, user names are case-insensitive and thus case does not matter for this entity. In a domain environment, users should be identified in the form: "domain\user name" For local users use: "computer name\user name" For built-in accounts on the system, use the user name without a domain. For example: ADMINISTRATOR, SYSTEM, etc. Note that the built-in user names should be all caps to help improve readability as that is how the windows apis return them. Of course techincally it does not matter since the names are case-insensitive.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="usersteuser" xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:rule context="win-def:user_state/win-def:user">
<sch:assert test="not(@datatype) or @datatype='string'">
<sch:value-of select="../@id" /> - datatype attribute for the user entity of a user_state should be 'string'</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="enabled" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>This element holds a boolean value that specifies whether the particular user account is enabled or not.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="usersteenabled" xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:rule context="win-def:user_state/win-def:enabled">
<sch:assert test="@datatype='boolean'">
<sch:value-of select="../@id" /> - datatype attribute for the enabled entity of a user_state should be 'boolean'</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="group" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>A string the represents the name of a particular group. In Windows, group names are case-insensitive and thus case does not matter for this entity. In a domain environment, groups should be identified in the form: "domain\group name" For local groups use: "computer name\group name" For built-in accounts on the system, use the group name without a domain. For example: ADMINISTRATORS, etc. Note that the built-in group names should be all caps as that is how the windows apis return them. Of course techincally it does not matter since the names are case-insensitive.</xsd:documentation>
<xsd:documentation>The group element can be included multiple times in a system characteristic item in order to record that a user can be a member of a number of different groups. Note that the entity_check attribute associated with EntityStateStringType guides the evaluation of entities like group that refer to items that can occur an unbounded number of times.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="userstegroup" xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:rule context="win-def:user_state/win-def:group">
<sch:assert test="not(@datatype) or @datatype='string'">
<sch:value-of select="../@id" /> - datatype attribute for the group entity of a user_state should be 'string'</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
|
XSD Schema Diagram:
