Re: [office] Conformance Clauses and NVDL

[Jirka Kosek <jirka@kosek.cz>]

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:

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

I don't think that such rules for RELAX NG are complex. Have you read
the following message:

http://lists.oasis-open.org/archives/office/200808/msg00099.html

it contains one possible way to overcome this "ambiguity issue".

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

Yes this is also option but only if MathML fragment is always enclosed
in a single ODF element which is currently the case, my reading of
schema is that MathML is allowed as only child in db:component and
draw:object elements.

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

This feature is considered for future versions of NVDL. If there is
demand for it from ODF this can accelerate adoption I think. Some NVDL
validators provide this functionality as an extension, e.g.:
http://jnvdl.sourceforge.net/extensions.html#extensions-usewhen

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

I know that this might seem little bit impertinent on this list, but
OOXML defines very good and robust approach for extensibility, see:

http://www.ecma-international.org/cgi-bin/counters/unicounter.pl?name=ECMA-376_part5pdf&deliver=http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

or if you are member of SC34 you can access the actual text which will
became part of ISO/IEC 29500:

http://www.itscj.ipsj.or.jp/sc34/def/1082.pdf

				Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

OpenPGP digital signature