Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>One simple way to solve your problem in XSD 1.0 is to change the terms of the problem slightly: replace the current <code>WSUpdate</code> element with an abstract element of the same name; define <code>Update</code> and <code>Remove</code> elements which are substitutable for it. Declare attributes as optional or required on <code>Update</code> and <code>Remove</code> as desired.</p> <p>All that's needed to check conditions like this in XSD 1.0 is that the conditions depend on the element names and not on other properties of the elements.</p> <p>[EDITED 12 Sept 2012: The OP asks for a more complete example.]</p> <p>Here is a simple example of the use of abstract elements.</p> <p>First we make <code>UpdateAccount</code> type refer to its child element rather than declaring it locally. This allows other elements to refer to it, too, and declare themselves substitutable for it. </p> <pre><code>&lt;xs:element name="UpdateAccount"&gt; &lt;xs:complexType&gt; &lt;xs:sequence&gt; &lt;xs:element minOccurs="0" maxOccurs="1" ref="tns:myAccount" /&gt; &lt;/xs:sequence&gt; &lt;/xs:complexType&gt; &lt;/xs:element&gt; </code></pre> <p>Then we declare the <code>myAccount</code> element itself as an <em>abstract</em> element. No elements actually named <code>myAccount</code> will be accepted, only concrete elements declared as being substitutable for <code>myAccount</code>.</p> <pre><code>&lt;xs:element name="myAccount" abstract="true"/&gt; </code></pre> <p>Then we declare two concrete elements substitutable for <code>myAccount</code>, and give them types with the appropriate constraints. The <code>action</code> child element is no longer needed: the difference between deletion and update is now given by the name of the element (<code>update</code> vs <code>remove</code>).</p> <pre><code>&lt;xs:element name="update" type="tns:WSUpdate" substitutionGroup="tns:myAccount"/&gt; &lt;xs:complexType name="WSUpdate"&gt; &lt;xs:sequence&gt; &lt;xs:element minOccurs="1" maxOccurs="1" name="ID" type="xs:int" /&gt; &lt;xs:element minOccurs="1" maxOccurs="1" name="Name" nillable="false" type="xs:string" /&gt; &lt;/xs:sequence&gt; &lt;/xs:complexType&gt; &lt;xs:element name="remove" type="tns:WSDelete" substitutionGroup="tns:myAccount"/&gt; &lt;xs:complexType name="WSDelete"&gt; &lt;xs:sequence&gt; &lt;xs:element minOccurs="1" maxOccurs="1" name="ID" type="xs:int" /&gt; &lt;xs:element minOccurs="0" maxOccurs="1" name="Name" nillable="false" type="xs:string" /&gt; &lt;/xs:sequence&gt; &lt;/xs:complexType&gt; </code></pre> <p>In some contexts it might be desirable to declare the element <code>myAccount</code> as having a named type (like the <code>tns:WSUpdate</code> in your original example) and to declare the types of <code>update</code> and <code>remove</code> as being restrictions of that type. That would make the example somewhat longer and more tedious, so I content myself with mentioning it here. Whether it makes sense depends on how well you trust the people who will maintain the schema and whether your other schema-aware tools will do useful things with the information.</p>
    singulars
    1. This table or related slice is empty.
    1. POXSD condition based on element value
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USC. M. Sperberg-McQueen
    1. USC. M. Sperberg-McQueen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POXSD condition based on element value
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI am not strong in XSD at all. Do you mind giving me an XSD example based on my sample above please? Thanks
      singulars
      1. PO
      1. USGeorge
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload