Re: [office] Conformance Clauses and NVDL

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Jirka,

On 10/20/08 06:46 PM, Jirka Kosek wrote:
> 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".

If we could really exclude namespaces we are defining ourselves then
this would be a solution. But with ODF 1.2 we have introduced xml:id,
and we can't exclude this attribute within XForms model content.

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

Yes, that is correct. We have a limited number where MathML is allowed,
and the same applies to XForms models.
> 
>>> 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

Thanks. I didn't know that. Anyway, using this feature would only be an
option if it would exist in NVDL already today or in the very near 
future. Do you when an NVDL standard will be available that does include 
this feature?

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

The NVDL script provided in this document checks whether elements and 
attributes from the markup compatibility namespace are syntactically 
correct. But it is my understanding that it does not consider its 
semantics. That means that is does not automatically attaches the 
content of an element if its name appears in the value of an 
ProcessContent attribute. It's my understanding that this still requires 
an NVDL script that is tailored to the extension elements that are used.

Michael

> 
> 				Jirka
> 


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