Re: [office] Two JIRA Issues for discussion

[Patrick Durusau <patrick@durusau.net>]

Michael,

I am torn between saying that we have known the "style" of the schema 
(use of combine) was an issue for some time and agreeing with you that 
ODF-Next would be a better target for such a change.

Suggestion: You have spoken of having a more software production type 
schedule for ODF, so that users could know when (approximately) new 
features could be expected, etc. Could that be an answer to this and 
similar questions if we fix an even tentative date for ODF-Next to 
appear? So that our answer isn't "someday" but a more certain date in 
the future? Which would allow us to back off from that date to establish 
feature freezes, etc.

I did find a resource that may be a partial answer to the comparison 
issue, see http://www.brics.dk/schematools/, but that involves the 
production and comparison of XML graphs. I suspect such a comparison 
would be sufficient but I don't think enough time remains to be entirely 
certain on that score.

On the whole, I think making sure that the additions/changes we have 
already made are of a higher priority that schema style issues (granting 
those are important as well, but there are only so many hours in a day).

Hope you are at the start of a great week!

Patrick

On 2/22/2010 8:25 AM, Michael Brauer - Sun Germany - ham02 - Hamburg 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.
>
>
>>
>>
>> 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
>>
>>
>
>

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)