OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on id constraints



Hi John,

> The spec says that the selector must involve the child axis. This
> imples that in the following example:
>
> <files>
>   <file>
>     <directoryid>
>     <fileid>
>     <filetype>
>   </file>
>   <file> . . . etc
>
> </files>
>
> I would not be able to specify a unique or key for <file> consisting
> of the combination of <directoryid> & <fileid>, since the selector
> must point to either one or the other of these, unless the key is
> specified in the parent <files>.

I'm a bit confused by your terminology. The key has to be specified in
the parent files element because of the scope of the key - nothing to
do with the combination of fields. You can work out the key that you
need in XML Schema by completing the following sentence: "All X
elements within the Y element have a unique combination of A, B and
C."

The X elements are the things that should have an ID. In your case
these are the file elements. The Y element is an element that holds
all the X elements, often but not always the document element. In your
case that's the files element. The A, B and C elements or attributes
are children of or attributes on the X element that can be used to
identify it. In your case that's directoryid and fileid.

Now, the xs:unique element always needs to go in the element
declaration for the Y element. In your case that's the element
declaration for the files element; you should have something like:

<xs:element name="files" type="filesType">
  <xs:unique name="file-directory-and-file">
    ...
  </xs:unique>
</xs:element>

The xs:unique element needs to hold a single xs:selector element. This
xs:selector element points from the Y element to the X elements. In
your case that points to the child file elements of the files element:

<xs:element name="files" type="filesType">
  <xs:unique name="file-directory-and-file">
    <xs:selector xpath="file" />
    ...
  </xs:unique>
</xs:element>

After the xs:selector come a number of xs:field elements, each of
which points from the X element to the A, B and C elements or
attributes. In your case, you need one for the directoryid child of
the file element, and another for the fileid child of the file
element:

<xs:element name="files" type="filesType">
  <xs:unique name="file-directory-and-file">
    <xs:selector xpath="file" />
    <xs:field xpath="directoryid" />
    <xs:field xpath="fileid" />
  </xs:unique>
</xs:element>

> Anyone know if this is correct? It seems a bit limiting since I
> can't then reuse that constraint in other contexts where <file> is
> used without redefining it.

You are right that you can't reuse the identity constraints in other
contexts, aside from through copy and paste or entities if you're
feeling brave. You also can't use identity constraints across
documents or use axes other than the child or attribute axes in the
xpaths. For example, if your source was:

<files>
  <directory>
    <directoryid>...</directoryid>
    <file>
       <fileid>...</fileid>
    </file>
    ...
  </directory>
  ...
</files>

Then you couldn't say that within the files element every file element
has a unique combination of fileid and parent directory's directoryid
(though this would only matter if you could have several directory
elements with the same directoryid).

I suspect that these things are just the wrong side of the 80/20 split
:(

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/