[dsdl-discuss] Re: Fw: [office-comment] Ambiguity problems caused by a:defaultValue

At 2008-05-10 12:26 +0900, MURATA Makoto wrote:
>I have been always against default values. People incorrectly
>use a:defaultValue in RNG schemas, while no implementations
>point out the problems. ;-(

I support any decision to deprecate and remove default values in
schema specifications. I like your ODF suggestion of just
documenting the interpretation of absent items ... that's what I do
in my RELAX-NG schemas for my customers ... I don't bother with a:*.

. . . . . . . . . . . Ken

>Regards,
>
>Forwarded by "MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>
>----------------------- Original Message -----------------------
> From: "MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>
> To: office-comment@lists.oasis-open.org
> Date: Sat, 10 May 2008 12:21:39 +0900
> 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>

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/d/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/d/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)