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] Conformance Clauses and NVDL

Hi Jirka,

On 10/03/08 16:37, Jirka Kosek wrote:
> Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>> I have uploaded a first NVDL script here:
>> http://www.oasis-open.org/committees/download.php/29455/odf.nvdl
>> It probably requires some more work, but it shows already what
>> using NVDL would look like.
> ...
>> One last remark: NVDL is new to me. So, any support with further
>> developing the script is welcome.
> Hi Michael,
> I haven't had enough time to study your NVDL script and conformance
> proposal in detail. But I think that moving to NVDL is right approach.
> So far, I have noticed one problem in NVDL script. Instead of:
> <namespace ns="http://www.w3.org/1998/Math/MathML";>
>   <validate schema="../../specs/mathml2/mathml2.xsd"/>
> </namespace>
> you should use
> <namespace ns="http://www.w3.org/1998/Math/MathML";>
>   <validate schema="../../specs/mathml2/mathml2.xsd"/>
>   <attach/>
> </namespace>
> (and similar change for XForms)
> This will validate MathML fragments against MathML schema, but at the
> same time MathML fragment will stay in its place and will be validated
> against ODF RELAX NG schema which defines where MathML fragments can
> appear. Without <attach/> NVDL script will allow MathML fragment to be
> anywhere.

Thanks for this hint. You are right. The current script allows MathML
everywhere. I'm not sure if an <attach> actually solves this issue.

My understanding is that <attach> adds the MathML fragment to its
parent element before validation takes place. This means that the ODF
schema either must include definitions for MathML, or must allow
anything where MathML may occur. In DTDs we may just define that the
<math:math> element's content is ANY, and there may be a similar concept
in XSD. In Relax-NG we need some complex rules here, and these rules
cause ambiguity issues regarding the Relax-NG DTD compatibility

Actually the current ODF schema already allows anything within
<math:math> elements. The ambiguity issues this causes regarding the
Relax-NG DTD Compatibility specification are one reason why I have
suggested to use NVDL instead.

I think another solution to limit the places where <math:math> may occur
is the use of a <context> element. Maybe its also an option to use the
<attachPlaceholder> element.

> In NVDL you can also very easily define that foreign elements/attributes
> are allowed everywhere. This is something which should be really defined
> on schema level, rather only in prose (which is the current state of
> affair in ODF spec).

I agree, but there is one problem. We currently have an attribute
"office:process-content" which specifies whether the content of an
element should be processed or not. The correct NVDL action if the value
of this attribute is "false" would be to ignore the element. The correct 
action if the value of this attribute is "true" would be an <unwrap>.
Unfortunately it seems not to be possible to take one of the other
action in an NVDL scripts based on an attribute value.

Well, the fact that this behavior cannot be described by NVDL may 
provide a reason to reconsider this feature. I believe that in most 
cases the content of foreign elements should be processed if the element 
occurs within paragraphs, and should be ignored in all other cases. We 
may therefore consider to deprecate the office:process-content attribute 
and could instead define that within paragraphs an <unwrap> action takes 
place, and that foreign elements are ignored in all other cases. For the 
few cases where this does not work, we have the new RDF based matadata 
features, that in any case provides a powerful alternative to use 
foreign elements.

Best regards


> You can find some more discussion about using NVDL for ODF validation here:
> http://lists.dsdl.org/dsdl-comment/2008-06/0005.html
> 			Jirka

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, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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