OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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 

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 

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. 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]