Print

Print


From: "Karen Coyle" <[log in to unmask]>
> I notice that madsCollection is commented out. Is it coming back?

I wasn't going to bring this up until I had time to work more on it, but
since you asked .....

XMLSpy isn't entirely going along with this "collection" idea.  I might not
have the latest version, and perhaps another editor will do better, but for
now this is what we have to work with (at LC)

. We don't want to publish schemas that don't validate or let you create
instances properly (unless we can document that it is strictly an editor
bug).   I hope other people might have some insight into this.

Anyway, try this exercise:

1. Begin a MODS instance with XMLSpy (ctrl N, "XML document", "schema";
mods). Note that you will be prompted for a root element, and among the
choices are mods and modsCollection. (Thus for MODS, XMLSpy appears to
behave correctly.)

2. Modify the MADS schema such that madsCollection is defined:  Better yet:
try the following  very simple schema:

-----------------------
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.loc.gov/xxx"
xmlns="http://www.loc.gov/xxx"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <xsd:element name="mads/>
 <xsd:element name="madsCollection">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="mads" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 </xsd:schema>
--------------------------------------------

This defines two root element, mads and madCollection, where madsCollection
is defined in terms of mads.

Begin an instance, as in (1).  Note that you don't even get prompted for a
root element, the root element is forced to be madsCollection.  If things
worked right, you'd get promted for a root element with choices mads and
madsCollection.   Things don't work right, because one root element
references another; however in MODS above, things worked right.

3. Just to prove that it's the relationship defined between the two elements
that causes the problem: Simplify even further, by removing the
relationship:
---------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.loc.gov/xxx"
xmlns="http://www.loc.gov/xxx"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="mads"/>
 <xsd:element name="muds"/>
 </xsd:schema>
_____________________________________________________

Thus two unrelated root elements are defined.

This time you'll get prompted for a root element, choices mads and muds, as
you should. (This is simply to illustrate the property that If your schema
defines a number of root element, you do get to choose from that set of
elements when creating an instance, as long as none  of those elements is
defined in terms of another.)

4. Now go back to MODS.
Replace:
 <xsd:any processContents="skip" maxOccurs="unbounded"/>
with:
<xsd:element name="xxx" maxOccurs="unbounded"/>

(In effect, get rid of 'any'.)

Try to create an instance.  Now you don't get prompted for a root element,
it forces the root element to be modsCollection.   This means (apparently)
that the presence of 'any' in MODS hides this flaw in XMLSpy.

(End of exercise.)


And the point?   If you write a schema that defines a number of root
element, you want your editor to let you choose from that set when creating
an instance.  Apparently this is a problem (at least for XMLSpy) when one of
those elements is defined in terms of another.  Except it's not a problem in
certain cases.  But precisely what those case are or why, remains a mystery
to me.

This problem wasn't discovered initially, because MODS met the
pre-condition -- it had a type defined as 'any' -- until by sheer accident
one day, I tried to validate a version where that element was missing.

That's as far as I've gotten with this, and it gives me great pain to think
of how much time I've wasted.

I hope at least a few of you will take the time to go through this (if
you've even gotten this far).


--Ray