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


On 22 February 2010 13:25, Michael Brauer - Sun Germany - ham02 -
Hamburg <Michael.Brauer@sun.com> wrote:
> Hi,
> On 02/19/10 16:28, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>> Hi
>> 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.
> A few more comments:
> - There is to the best of my knowledge no normative RNG schema for W3C
> XML Digital Signatures.
> - The TC agreed as one of its first decisions when it started its work
> that the schema language for ODF is RNG. That is the reason why the ODF
> digital signature schema is defined as an RNG schema.
> - The issue that the schema currently does not restrict the content of
> <ds:Signature> element could be solved by NVDL. The use of NVDL is
> already on the agenda for ODF-Next, but not a simple task.
> - We have other places where we cannot include definitions for elements,
> because they are defined by XSD only. That's XForms and MathML. So, the
> issue is a more general one.
> - A work-around for the digital signature schema could be to use XSD for
> that schema, and only for that schema. This would mean that we have a
> single schema where we exceptionally use XSD rather than RNG.
> - The possibility to automatically verify the content of a
> <ds:Signature> element by a tool does not depend on defining the
> permitted content of the element in the schema. If the specification
> states that the content of that element must follow a particular schema,
> and that is what we do, when a validation tool can implement that.
> My personal opinion here is that we should keep the schema as is for two
> reasons
> a) Consistency: using XSD for just one schema is not very consistent.
> b) It seems to be more reasonable to address the general issue in
> ODF-Next by switching to NVDL.

I do agree with this.  We are in this committee providing the
specification rather than the validation tool.  And the specification
seems to be quite unambiguous and authoritative in its references.  It
seems that providing for an NVDL based validation would be a really
worthwhile endeavour, but not really an absolute requirement at this


>> 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?
> Again, a few more comments
> - The current schemas are valid RNG. I'm not aware of any hints in the
> RNG specification that the "combine"-attributes should not be used in
> the way the ODF schema does use them.
> - The comment I've mentioned has an XSLT style sheet attached that turns
> combine attributes into <choice> and <interleave> elements. The style
> sheet looks correct, so the effort to just adapt the schema appears to
> be limited.
> - I'm not aware of a tool that checks if two RNG schemas are equivalent.
>  If no one else is aware of such a tool, there is no way of checking
> this automatically.
> - I could adapt the odftoolkit.org ODF validator to use the adapted
> schema. That provides some basic testing of an adapted schema.
> I'm actually a little but undecided what to do here. On the one hand,
> the effort and risk to remove the combine attributes seems to be
> limited, given that we received a contribution that simplifies that
> task. But on the other hand, the current ODF schema is a valid RNG
> schema and we are already in a late phase of the ODF 1.2 development where
> we should limit changes to things that are real issues.
> Best regards
> Michael
>> Michael
> --
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>           D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
> Vorsitzender des Aufsichtsrates: Martin Haering
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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