'''Note:''' this issue has now been addressed with [changeset:2011 a schematron check] (= solution 1 + a warning, to be incorporated somehow in the Component Registry) 

== problem ==

cmdi-price component:
{{{
<CMD_ComponentSpec isProfile="false">
  <Header>
    <ID>clarin.eu:cr1:c_1271859438115</ID>
    <Name>Price</Name>
    <Description>Component Price contains information about the (different) price(s) for a resource</Description>
  </Header>
  <CMD_Component name="Price">
    <CMD_Element CardinalityMax="unbounded" CardinalityMin="1" ValueScheme="string" ConceptLink="http://www.isocat.org/datcat/DC-2460" name="Price"/>
  </CMD_Component>
</CMD_ComponentSpec>
}}}

This results in instances such as:
{{{
     <Price>
                    <Price></Price>
     </Price>
}}}

I know that this is not a problem in XML but one of my colleagues here
says: Bad style same element within the same element with different
content models. Do you have any recommendations for us? I mean usually I
would say that it should be
<Price><Amount>...<Currency>...<Description>...</Price> etc. avoiding
the "problem". He is sort of right and if he wants to use RegEx for
processing, it is certainly nicer.

== possible solutions ==

=== 1. leave it as it is ===

pro:
 * less work

con:
 * not really stylish
 * potentially confusing


=== 2. styleguide: use a suffix to indicate components ===

(non-binding) advice for the creators of a component to use a certain suffix, eg "c_"

(or similar: use the plural for the components, singular for embedded elements)

{{{
<CMD_Component name="c_Price">
    <CMD_Element CardinalityMax="unbounded" CardinalityMin="1" ValueScheme="string" ConceptLink="http://www.isocat.org/datcat/DC-2460" name="Price"/>
</CMD_Component>
}}}

pro: 
 * less confusion
 * still leaves the possibility to freely choose the instance tags (eg for interoperability with TEI headers)

con:
 * non-binding, so confusion is still possible if users do not adhere to the advice


=== 3. automatically append a suffix when generating XSD ===

{{{
<CMD_Component name="Price">
    <CMD_Element CardinalityMax="unbounded" CardinalityMin="1" ValueScheme="string" ConceptLink="http://www.isocat.org/datcat/DC-2460" name="Price"/>
</CMD_Component>
}}}

results in:

{{{
<xs:element name="c_Price">
        <xs:complexType>
         <xs:sequence>
          <xs:element maxOccurs="unbounded" minOccurs="1" type="xs:string"
                      dcr:datcat="http://www.isocat.org/datcat/DC-2460"
                      name="Price"/>
         </xs:sequence>
         <xs:attribute name="ref" type="xs:IDREF"/>
        </xs:complexType>
       </xs:element>
}}}

and thus in:
{{{
 <c_Price>
     <Price></Price>
 </c_Price>
}}}

pro:
 * binding, so no confusion anymore

con:
 * intransparent, because the instance tags (c_Price) look different than the component tags (Price), although this might be masked by the software (hiding the c_ prefix eg)
 * impossible to "emulate" other schemas literally like TEI (eg <c_textDesc> tags instead of <textDesc>)

=== 4. remove outer components in XSLT ===

change the XSD-generation XSLT so that it removes the outer component, so you would get

{{{
...
<Price></Price>
...
}}}

instead of 

{{{
<Price>
	<Price></Price>
</Price>
}}}


pro:
 * more intuitive (?)
 * easier to use in arbil (?)

con:
 * does not work when the component has other elements (eg in a <price> component, both <description> and <price>)
 * (probably) complex changes to the XSLT