How to define a "anywhere" node in my XSD

[david.deridder]

Hi,

I would like to specify in my XSD that the "Documentation" element can
be added everywhere in the XML document. A bit like the
xs:documentation node.

How can i declare this in my XSD?

An example
<a>
<b>
<Documentation/>
</b>
</a>

is valid

but also

<a>
<Documentation/>
<b>
<Documentation/>
</b>
<Documentation/>
</a>

Thanks for the help
David

 

[david.deridder]

(e-mail address removed) schreef:

Hi,

I would like to specify in my XSD that the "Documentation" element can
be added everywhere in the XML document. A bit like the
xs:documentation node.

How can i declare this in my XSD?

An example
<a>
<b>
<Documentation/>
</b>
</a>

is valid

but also

<a>
<Documentation/>
<b>
<Documentation/>
</b>
<Documentation/>
</a>

Another valid one could be

<a>
<Documentation/>
<Documentation/>
<Documentation/>
<b>
<Documentation/>
<Documentation/>
</b>
<Documentation/>

 

[Joseph Kesselman]

There's no easy syntax for that. You have to explicitly write your
schema so it says the documentation element can appear anywhere in any
of the individual element models.

One alternative might be to use the documentation element only in
non-validated documents, and require that it be filtered out before
validating.

 

[=?iso-8859-1?q?Jean-Fran=E7ois_Michaud?=]

Hi,

I would like to specify in my XSD that the "Documentation" element can
be added everywhere in the XML document. A bit like the
xs:documentation node.

How can i declare this in my XSD?

An example
<a>
<b>
<Documentation/>
</b>
</a>

is valid

but also

<a>
<Documentation/>
<b>
<Documentation/>
</b>
<Documentation/>
</a>

Thanks for the help
David

What you are asking for is equivalent to an inclusion in SGML. You
might want to look the SGML way if its an option to you. The price you
pay for more flexibility is a bigger complexity headache .

Regards
Jeff

 

[Peter Flynn]

Hi,

I would like to specify in my XSD that the "Documentation" element can
be added everywhere in the XML document. A bit like the
xs:documentation node.

[...]
What you are asking for is equivalent to an inclusion in SGML. You
might want to look the SGML way if its an option to you. The price you
pay for more flexibility is a bigger complexity headache .

One of the papers at the Extreme Markup meeting in Montreal earlier this
month suggested that some SGML features omitted from XML (including
Inclusion Exceptions) be reconsidered for a future version. Publishers
have a number of serious requirements which XML is currently unable to
support.

///Peter

 

[=?iso-8859-1?q?Jean-Fran=E7ois_Michaud?=]

Hi,

I would like to specify in my XSD that the "Documentation" element can
be added everywhere in the XML document. A bit like the
xs:documentation node.

[...]
What you are asking for is equivalent to an inclusion in SGML. You
might want to look the SGML way if its an option to you. The price you
pay for more flexibility is a bigger complexity headache .

One of the papers at the Extreme Markup meeting in Montreal earlier this
month suggested that some SGML features omitted from XML (including
Inclusion Exceptions) be reconsidered for a future version. Publishers
have a number of serious requirements which XML is currently unable to
support.

This would considerably enhance the expressive power of XML. I think it
would be a good thing . But they have to be careful not to complexify
too much either. The advantage that XML has over SGML is its
simplicity.

Regards
Jean-Francois Michaud

 

[Peter Flynn]

(e-mail address removed) wrote:
Hi,

I would like to specify in my XSD that the "Documentation" element can
be added everywhere in the XML document. A bit like the
xs:documentation node. [...]
What you are asking for is equivalent to an inclusion in SGML. You
might want to look the SGML way if its an option to you. The price you
pay for more flexibility is a bigger complexity headache .

One of the papers at the Extreme Markup meeting in Montreal earlier this
month suggested that some SGML features omitted from XML (including
Inclusion Exceptions) be reconsidered for a future version. Publishers
have a number of serious requirements which XML is currently unable to
support.

This would considerably enhance the expressive power of XML. I think it
would be a good thing . But they have to be careful not to complexify
too much either. The advantage that XML has over SGML is its
simplicity.

Yes, this is why it's unlikely to happen. Sadly the use of XML for
dealing with real-life text documents was sidelined in the mad rush
to use XML for handling data, for which it is not always suited.

///Peter

 

[Stefan Ram]

Yes, this is why it's unlikely to happen. Sadly the use of XML for
dealing with real-life text documents was sidelined in the mad rush
to use XML for handling data, for which it is not always suited.

I do not know XSD, but I guess that the above can already be
done today, by explicitly allowing this element for every
element (repeatedly for each element).

So the only problem of the OP might be that this has to be
repeated, but this can be eliminated by generating the XSD
from a program or using a preprocessor. I mean, who still
writes his XSD manually, today? (seriously; I don't know,
because I have no experience with XSD.)

One even might consider to write a tool that translates an
SGML-DTD to the best XSD-approximation, which would include
this capability.

 

[Peter Flynn]

I do not know XSD, but I guess that the above can already be
done today, by explicitly allowing this element for every
element (repeatedly for each element).

Oh yes (see earlier posts). The nice thing about Exceptions was that
they only had to be specified on the earliest ancestor element type,
and were then inherited to all descendants automatically. But they
are a DTD solution, not an XSD solution.

The solution, of course, is to use schema modelling software like
Relax/NG, as you imply.

///Peter