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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Ambiguity problems caused by a:defaultValue

Dear colleagues,

While trying to explain the reason of the bug Alex pointed out, I find
an even severer problem.  I have not noticed it, since I never use
default values.

Before explaining the problem, let me say that this is arguably a
problem in the RELAX NG side.  I am not trying to offend the ODF camp
but rather feel that the RNG and ODF camps should try to overcome
the problem together.

Let's consider the problem.  It is about default values specified 
in RELAX NG schemas.

First, the default value feature a:defaultValue) is not
implemented by Jing.  As far as I know, a:defaultValue specified in
RELAX NG schemas are silently ignored by any of the RELAX NG validator.  
Some data-binding tools of RELAX NG (e.g., Relaxer) might use 

Second, the ODF schema has an ambiguity problem about default values.
This problem is NOT detected by Jing.  This problem is similar to the
ambiguity problem about ID/IDREF, which was pointed out by Alex.

Let me show a schema having an ambiguity problem.

  namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0";
  start = foo1
  foo1 = element foo { 
          ([ a:defaultValue = "false" ] attribute id { text })?, foo2 }
  foo2 = element foo {   attribute id { text }? }

This schema does not satisfy the constraint in the last bullet of the
first itemized list of Section 3 in "RELAX NG DTD Compatibility".

>if the containing definition competes with another definition, then
>that other definition also contains an attribute element with the same
>name and with an a:defaultValue attribute with the same value.

In this schema, foo1 competes with foo2.  But foo2 does not specify 

But Jing does not report anything.

bash-3.2$ !!
java -jar d:/james/jing-20030619/lib/jing.jar -c test.rnc test.xml

The ODF 1.0 schema has the same problem.  For example, 

   [ a:defaultValue = "simple" ] attribute xlink:type { "simple" }

in the definition of office-meta-data.  This definition competes 
with anyElements (the last definition on the ODF 1.0 schema).  However,
anyElements does not specify a:defaultValue for the attribute 

It is not easy to solve the problem by changing the definition of
anyElements (and that of mathMarkup).  It is not impossible.  But the
result will be more difficult to read.  However, a:defaultValue is
ignored after all.

I would propose to replace every a:defaultValue with a comment, which
indicates what application programs should do when the attribute is
absent.  I believe that this is exactly what ODF application
programmers are doing right now.


MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>

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