wrote on 02/19/2010 10:28:56 AM:
>
> there are two JIRA issues I'd like to discuss in the next TC meeting:
>
> 1) http://tools.oasis-open.org/issues/browse/OFFICE-2215
>
> The question here is whether or not we want to switch to XSD as schema
> language for the digital signature schema.
>
I'm reading Murta-san's request as asking that we use a RNG schema for W3C
digital signatures if one is available. I'd agree, that if there is a
_normative_ RNG schema provided by the W3C we should adopt that. Does
such a thing exist? I don't want to use an informal RNG translation.
Although such an informal translation could be useful to some
implementers, we should remember that our citation of a schema is to
define the requirements of ODF documents. An implementor is free to use
the same schema we cite, an equivalent one in another schema definition
language, or even no schema at all, since validation is not a requirement
on ODF consumers.
So if we have these mixed schema language situations (and we have this
with MathML as well), we can solve this in a couple ways:
1) Use NVDL to define how the different sub document types should be
validated.
2) Give equivalent information in the body of our specification.
My guess is that Murata-san and others would prefer that we used NVDL. I
don't have a strong preference. We need to specify their relationship one
way or another. It seems easy enough to say (as we do today) "The
<xmldsig:Signature> element is defined by the [xmldsig-core]
specification." Maybe even put it stronger, as "The <xmldsig:Signature>
element shall conform to the [xmldsig-core] specification" or better "The
<xmldsig:Signature> element shall be a conforming XXX as defined by the
[xmldsig-core] specification."
>
> 2) http://tools.oasis-open.org/issues/browse/OFFICE-2214
>
> The question here is whether we want to make changes to the RNG schema
> right now, or for ODF-Next.
>
> We actually got a contribution for an ODF schema for part 1 that does
> not use the "combine" attribute:
>
> http://lists.oasis-open.org/archives/office-comment/201002/msg00022.html
>
> However, changing the schema in the last minute of cause has some risks.
> The current schema is well tested, and while there have been changes for
> ODF 1.2, it is in use since ODF 1.0.
>
> So, maybe, we should just switch to a new schema structure as first
> action for ODF 1.3/2.0 rather than the last one for ODF 1.2?
>
If we made a change at this point it could clearly introduce new bugs. But
we have still another 3-month review of ODF 1.2 ahead of us, so it is
possible to react. I guess the question is whether we are willing to test
the new schema over the next three months to ensure it is accurate? If we
find it is not, we always have the option to fix it (if the errors are
minor) or switch to the original version (if the errors are widespread).
So I think we have time to react.
What might be interesting is whether we could get the ODF validators --
the ODF Tool Kit union, the Office-o-tron and the OfficeShots one, to
start validating all of their documents twice -- once with the existing
schema and once with the re-factored schema. They can then highlight
whenever these two schemas differed in their results. I think that would
give us high confidence if they gave identical results over several
months.
So that is the risk and the possible way to mitigate it. What isn't clear
is what the benefit of this change is. Other than the current approach
seems to offend the aesthetic sensibilities of one person, do we know of
any tangible problems with the current approach? As you say, it has
worked fine, on a variety of RNG validators for 5 years now. I know
Murata-san says that it goes against the intent of the combine attribute,
it appears to be a conformant use of it.
Regards,
-Rob
