[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:*.

We could also think through whether the issue is not with defaulting but
that the wildcarding is not powerful enough. (The other problem with
defaulting and IDs is that undecidability issue that Bob Lyon's pointed
out a few years ago.)

I first wondered whether, perhaps there should be a non-competitive
wildcard that says that the effective definition is the union of
subordinate definitions. So if one default is "a" and the other "b" then
it is undefined which one holds, as long as it is one. That may be fine
for validation, and fits in with set operations perhaps, but it hardly
seems to advance the cause of rigorous markup :-) On the other hand,
maybe it could reflect some use case somewhere...just not the problem at
hand :-(

Another approach would be to give some simple scoping rules. Lexical
scoping is out of the question, I expect. But I don't see why some
top-down scoping is not reasonable. If two declarations at the same level
conflict, there is a conflict and reportable error. If a subordinate
definition conflicts, as in Murata-san's example, it is still a reportable
warning but validation continues with the superior one holding (or
whatever.)

How does XSD handle this? I think the UPA means at least some of the
problem should not occur.

I think we should be strongly guided by what is most convenient for our
users, of course, in particular ODF. While I think we all agree that
defaulting attribute values goes against the original
validation-not-preprocessor design of RELAX NG etc (to agree with Ken),
the ID issue is surely a matter of validation which users can reasonably
expect to have a simple answer in RELAX NG, without resorting to
Schematron etc.

I have just spent a week in Canberra teaching courses to govt. Geospatial
people. They use Schematron as part of their standard, and were aware of
RELAX NG (they have to use XSD because that is what the Geospatial
Consortium uses). And a couple of weeks ago I heard that most UK tax
returns go through Schematron, courtesy of the XBRL people. So we have ODF
and OOXML using RELAX NG too: these are all big and meaty and
*challenging* standards, and I don't think we need to be at all defensive
if we find some areas for improvement! It is a sign of success and
adoption, and a good chance for us to shine perhaps.

I agree with Murata-san that we should be really open and keen to get it
fixed. Kudos to Alex for discovering the problems. I wrote a blog (which
was even quoted on some of the usual suspect's blogs, but only from a
syndecated site that strips my unholy name off the blog.) I think we
should try to take this opportunity to show the OASIS ODF people that SC34
does try hard to provide a good and fair service and help our users in
standards bodies to progress.

I think underlying this is an expectation that RELAX NG schemas should
only report errors in markup, not nominal errors in schemas. When people
adopt RELAX NG, one of the reasons they do so is because they don't want
to have to put up with 1-ambiguity. It may be worthwhile to have a second
look at RELAX NG's static schema checks to see how many of them fit in
with this user expectation, perhaps?

Cheers
Rick Jelliffe

--
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)