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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: jing validation errors

Dear TC members,

When I wrote the xml:id proposal, my hope was that the restriction to a
single ID attribute would actually make it easier to make the schema
compatible with the RNG DTD Compatibility specification, which again
would resolve the errors that jing reports if called without "-i" option.

I did some research and experiments. However, I did not find a solution
for this. The reason is the following definition in the DTD
Compatibility specification[1]:

> A RELAX NG schema is compatible with this feature [ID/IDREF] if and 
> only if, after
> schema simplification, for each data or value element that specifies
> a datatype associated with a non-null ID-type, all of the following
> hold:
>     * its parent is an attribute element
>     * the first child of its attribute parent is a name element
>     * the first child of the element ancestor is a name element

Essentially this means that one can define an attribute of type ID only
if one provides the name of the attribute, and the name of an element.

Why is this an issue? We have a few places in the schema where we allow
arbitrary content, for instance within the <office:meta> element for 
meta data, or the <draw:object> element for embedded objects. XML 1.0 
DTD has the concept of an ANY content type for this. RNG does not have 
this. One needs a definition like this:

<define name="any">
	<ref name="any"/>

I have actually taken this from RNG Tutorial[2].

In a document which does not define ID attributes this works well. But
if there is a definition of an attribute of type ID somewhere in the
document (let's say an xml:id attribute), then this leads to an
ambiguity, because the above fragment implicitly defines an xml:id
attribute which has the RNG datatype "text". That means that there are 
two definitions for each occurrence of an xml:id attribute now. One 
explicit somewhere in the schema, and an implicit one generated from the 
above schema fragment. The first one defines the xml:id data type to be 
ID, the second one "text".

For pure RNG this is not an issue, but the RNG DTD Compatibility 
specification does not allow this. This ambiguity is reported by jing as 
an error in DTD compatibility mode. These are the error messages one 
currently gets when using jing for validation of ODF files without the 
"-i" switch.

The obvious solution to this would be to explicitly define an xml:id 
attribute with type ID:

<define name="any">
       <attribute name="xml:id">
         <data type="ID"/>
	<ref name="any"/>

But this does not work either, because the rules that the RNG DTD
Compatibility specification has for ID, and that I have cited above,
require that the names of the elements on which the "xml:id" attribute
can occur are defined by <name> elements, but not by name classes like
<anyName>. Jing therefore reports the following error for this fragment:

an "element" pattern containing an "attribute" pattern with a non-null
ID-type must have a name class that contains only "choice" and "name"

MSV reports a similar warning. Only if one replaces the "anyName" above 
with "<name>any</name>" the error message disappears. But this defines 
an element with name "any" rather than an element that may have an 
arbitrary name.

That means, the only way to get compliant with the RNG DTD Compatibility 
specification (and to get no error messages for jing without disabling 
RNG DTD Compatibilty) would be to list the names of all elements that 
can take an xml:id attribute. For our own schema fragments we do know 
them. That is not an issue. But we don't know them for fragments we 

Well, we could forbid xml:id attributes in fragments we include, but 
this means ODF does not support the inclusion of schema fragments that 
contain xml:id attributes. That does not seem to be reasonable either.

I would be glad if my analysis of the issue is incorrect, but right now,
I don't see any other solution than avoiding any reference to the RNG
DTD Compatibility specification, and to provide the advice to use RNG
with the "-i" switch.

Best regards


[1] http://www.oasis-open.org/committees/relax-ng/compatibility.html

[2] http://www.oasis-open.org/committees/relax-ng/tutorial.html

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]