«

Hello,

I'd like to write a single XML Schema for both these documents :

<Items>
<Item xml:id="id1">
<Name>ABC</Name>
...
</Item>
<Item xml:id="id2">
<Name>DEF</Name>
...
</Item>
...
</Items>

and

<Items>
<Item ref="id1"/>
<Item ref="id2"/>
...
</Items>

That looks "easy", but I've been googling for hours and tried so many
differents combinations of <choice> and <sequence>'s... and yet it
doesn't work :/
All I got at best were errors saying "local complex type: The content
model is not determinist" -- because the element name "Item" is used in
both "types" of elements IIUC.

Maybe using more complex OO features of XML Schema would somehow help me
out?

Cheers,

--
Damiano ALBANI

Damiano ALBANI wrote:
> Hello,
>
> I'd like to write a single XML Schema for both these documents :
....

How about a schema that declares:
- Items elements to contain any number of Item elements (maybe any
number > 0, up to you)
- Item elements to have an optional id attribute, an optional ref
attribute and a sequence of Name sub-elements of length 0 or 1

> That looks "easy", but I've been googling for hours and tried so many
> differents combinations of <choice> and <sequence>'s... and yet it
> doesn't work :/

You will have to tell us about what it must be able to do, what you
tried, what you expected and what you got....

One solution is to approximate Items to contain anything at all. That
will work -- but is that good enough for your requirements?

> All I got at best were errors saying "local complex type: The content
> model is not determinist" -- because the element name "Item" is used in
> both "types" of elements IIUC.
>
> Maybe using more complex OO features of XML Schema would somehow help me
> out?

NO. They will only make it worse

An XML Schema must be written in such a way that it can be <<determined
immediately when parsing what branch of a content model to use>> (my
formulation; The XML Schema spec has some formally correct but so
complicated that you can't read it ways to say that).

Example

<element name="goat">
<complexType>
<choice>
<sequence>
<element name="foo"/>
<element name="bar"/>
</sequence>
<sequence>
<element name="foo"/>
<element name="baz"/>
</sequence>
</choice>
</complexType>
</element>

--- when validating:
<goat>
<foo/>
<baz/>
</goat>

(which is valid), the schema must be constructed that the validator,
when it sees the <foo/> element, does not have to _guess_ whether to
continue validating as
<sequence>
<element name="foo"/>
<element name="bar"/>
</sequence>

or

<sequence>
<element name="foo"/>
<element name="baz"/>
</sequence>

You have probably made that mistake

A possible fix is:

<element name="goat">
<complexType>
<sequence>
<element name="foo"/>
<choice>
<element name="bar"/>
<element name="baz"/>
</choice>
</sequence>
</complexType>
</element>


Hope that helped.

Søren

Thanks for the tips Soren !

Here's what I wrote, which works quite well -- not perfectly, but the
best I could thought of :

<xsd:group name="Item_Content">
<xsd:sequence>
<xsd:element name="Name"
type="xsd:string"/>
<xsd:element name="Type"
type="xsd:string"/>
...
</xsd:sequence>
</xsd:group>


<xsd:complexType name="Item_Type">
<xsd:group ref="Item_Content"
minOccurs="0"
maxOccurs="1"/>
<xsd:attribute name="id"
type="xsd:ID"/>
<xsd:attribute name="ref"
type="xsd:IDREF"/>
</xsd:complexType>

So, the only problem is that an Item element with both (content + @id)
_and_ @ref attribute is considered valid.

In my real-world application, I don't manipulate simply Item elements
but there's several complex element types. So that means I need to write
many "dual" element definitions (content through <xsd:group> + actual
type referring to that group). As I'm no expert in XML Schema, would
there be a way to avoid this redundancy ?

Cheers,

--
Damiano ALBANI

Damiano ALBANI wrote:
> Thanks for the tips Soren !

Happy to be of help
> So, the only problem is that an Item element with both (content + @id)
> _and_ @ref attribute is considered valid.

Can't do anything about that. Attribute inter-dependencies are not
supported in XSD.

> In my real-world application, I don't manipulate simply Item elements
> but there's several complex element types. So that means I need to write
> many "dual" element definitions (content through <xsd:group> + actual
> type referring to that group). As I'm no expert in XML Schema, would
> there be a way to avoid this redundancy ?

Sorry, don't understand that. Could you post an example?

Søren

Soren Kuula wrote:

>> So, the only problem is that an Item element with both (content + @id)
>> _and_ @ref attribute is considered valid.
>
> Can't do anything about that. Attribute inter-dependencies are not
> supported in XSD.

Okay.

>> In my real-world application, I don't manipulate simply Item elements
>> but there's several complex element types. So that means I need to
>> write many "dual" element definitions (content through <xsd:group> +
>> actual type referring to that group). As I'm no expert in XML Schema,
>> would there be a way to avoid this redundancy ?
>
> Sorry, don't understand that. Could you post an example?

I was referring to the example in my post. For each element type, I need
to define :

* a <xsd:group>
* a <xsd:complexType>, using the previous <xsd:group>

So I was thinking of an XML Schema construct to avoid "leaking"
<xsd:group> definitions outside <xsd:complexType> where they are used.
No big deal, but that would make the final schema a bit "cleaner".

Cheers,

--
Damiano ALBANI

Damiano ALBANI wrote:
> Soren Kuula wrote:
>
>>> So, the only problem is that an Item element with both (content +
>>> @id) _and_ @ref attribute is considered valid.
>>
>>
>> Can't do anything about that. Attribute inter-dependencies are not
>> supported in XSD.
>
>
> Okay.
>
>>> In my real-world application, I don't manipulate simply Item elements
>>> but there's several complex element types. So that means I need to
>>> write many "dual" element definitions (content through <xsd:group> +
>>> actual type referring to that group). As I'm no expert in XML Schema,
>>> would there be a way to avoid this redundancy ?
>>
>>
>> Sorry, don't understand that. Could you post an example?
>
>
> I was referring to the example in my post. For each element type, I need
> to define :
>
> * a <xsd:group>
> * a <xsd:complexType>, using the previous <xsd:group>
>
> So I was thinking of an XML Schema construct to avoid "leaking"
> <xsd:group> definitions outside <xsd:complexType> where they are used.
> No big deal, but that would make the final schema a bit "cleaner".
>
Well you don't *have* to use a group when making a complex type. I think
you can always replace a group reference by the content of the referred
group. It's just a sort of macro mechanism.

Søren