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

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.

> 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 Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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

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