[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Two JIRA Issues for discussion
Michael.Brauer@Sun.COM 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]