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

The DTD compatibility spec imposes sever restrictions on competition:
two definitions compete if the same elemnt name matches both. But
this restriction could have been lighter. For example, consider
the following schema.

start = element foo {bar1, bar2}
bar1 = element bar1 {baz1}
bar2 = element bar2 {baz2}
baz1 = element baz {attribute id { ID }, xsd:string}
baz2 = element baz {xsd:int}

Here baz1 and baz2 compete. baz1 defines @id as an ID, while baz2
does not. So, this schema is not compatible, as defined by
the DTD compatibility spec. However, baz1 occurs in <ba1>,
while baz2 occurs in <bar2>. That is, "competition" actually
does not happen.

In fact, an earlier version of RELAX NG allowed this schema. It
was the original design by James. I strongly opposed. Thus, we
have created the DTD compatibility spec.

I still think that we should not use validation against the above
schema as the mechanism for attaching ID-ness to attributes. Such
an approach will make validation mandatory.

Since the DTD compatibility spec imposes a big restriction, it is easy
to write an application program that maintains a hash table. It only
has to add a key-value pair whenever it encounters ID attributes.
We only have to make sure that the name of the containing element
is allowed by the corresponding definition. That approach does not
work for the above schema (note that "baz" matches both baz1 and baz2).
Rather, the application program has to examine the path from the root.
In my opinion, this is just too difficult.

I can imagine that many of the ODF and ODF implementations do not
use validation anyway. In fact, ODF implementations cannot
use validation, since the ODF specification allows foreign elements
that are not allowed by the schema. The same thing applies to ODF,
thanks to Markup Compatiblity and Extensions.

Cheers,

-- 
MURATA Makoto <murata@hokkaido.email.ne.jp>
--
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)