RE: [office-comment] Ambiguity problems caused by a:defaultValue

["Alex Brown" <alexb@griffinbrown.co.uk>]

Murata-san, all,

I agree this is another problem with the ODF schema. I also agree that
the DTD compatibility feature of RNG is dangerous and problematic. I
continue to believe it should not be standardised in JTC 1.

Msv (though it does not fully implement attribute defaulting) does
detect this class problem with the ODF schema. It reports:

"There are more than one patterns that can match the "tracked-changes"
element, and some of them have attribute default values and some of them
dont. For the schema to be compatible, there must be a functional
mapping from element and attribute names to default values."

I would class this the same as the ID problem: it is an unresolvable
ambiguity. Msv also reports [1] that attribute defaulting has been
declared improperly for 22 attributes (I have not checked this yet).

Jing does not claim to implement attribute defaulting at any level, so
it is not surprising it reports no problem. I don't believe there are
any implementations of RNG attribute defaulting to the level required by
ODF (though I am working on rectifying this).

I strongly agree that (ideally) attribute defaulting should not be used:
it is better practice simply to document an expectation of how
attributes absences are to be interpreted.

In fact I think that (ideally) the schema should be re-written so that
its dependency on DTD-compatibility features is removed, and the
standard can then remove the reference to this troublesome spec. But
that is obviously quite a change.

If this were done, the ID semantics (currently declared using
DTD-compatibility) could be supplied, in the modern manner, by using W3C
xml:id [1]. This enjoys a reasonable level of application support (not
Xerces though - last time I looked), and works very well in my
experience. Then it would no longer be necessary to apply a
DTD-compatible validator to ODF instances on each and every occasion
they were processed.

Personally, I would remove all the XSD datatyping from the ODF schema
too so that the schema became "pure" 19757-2 -- but I appreciate that is
perhaps more of a religious discussion, not to mention a radical change!
At least if these XSD datatypes remain, the OASIS document that explains
their implementation in RNG [3] should be referenced (currently it is
not).

[1] http://www.griffinbrown.co.uk/blog/images/odf10-msv-warnings.txt

[2] http://www.w3.org/TR/xml-id/

[3] http://relaxng.org/xsd-20010907.html


- Alex.


> -----Original Message-----
> From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt@asahi-net.or.jp]
> Sent: 10 May 2008 04:22
> To: office-comment@lists.oasis-open.org
> Subject: [office-comment] 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
> a:defaultValue.
> 
> 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
> a:defaultValue.
> 
> But Jing does not report anything.
> 
> bash-3.2$ !!
> java -jar d:/james/jing-20030619/lib/jing.jar -c test.rnc test.xml
> bash-3.2$
> 
> The ODF 1.0 schema has the same problem.  For example,
> consider
> 
>    [ 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
> xlink:type.
> 
> 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.
> 
> 
> Cheers,
> 
> --
> MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
> 
> 
> --
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/office-comment/
> Feedback License: http://www.oasis-
> open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-
> open.org/committees/tc_home.php?wg_abbrev=office