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

Rick, all,

This (below) is what I posted to odf-comment.

One thing maybe this raises is that we (DSDL'ers) have lost sight of the
need for a specialised key/keyref type validation mechanism which (I
believe) at one time was seen as a necessary part of the Standard.

- Alex.

> -----Original Message-----
> From: Alex Brown
> Sent: 10 May 2008 07:04
> To: MURATA Makoto (FAMILY Given); office-comment@lists.oasis-open.org
> Subject: RE: [office-comment] Ambiguity problems caused by
> a:defaultValue
>
> 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 [2]. 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.

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