Dear TC members,
I have integrated below thoughts into a fourth iteration of the
conformance clause proposal:
http://www.oasis-open.org/committees/download.php/29584/conformance-definition-proposal-v2.odt
I have further created a Proposal Wiki page for the proposal:
http://wiki.oasis-open.org/office/Conformance
I would like to discuss this proposal in the next call.
Please note that I did not add anything related to NVDL to the
conformance clauses so far. The use of NVDL would not effect the
requirements a conforming document must meet, but we would only state
them in NVDL scripts rather than as text. And of cause we would
reference NVDL scripts rather than Relax-NG schemas in the conformance
clauses.
I will submit a separate proposal regarding NVDL when we have agreed on
the content of the conformance clauses itself.
Best regards
Michael
On 07.10.08 15:43, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> 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
> specification.
>
> 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
>
> Michael
>
>
>>
>> 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
StarOffice/OpenOffice.org
Sun Microsystems GmbH Nagelsweg 55
D-20097 Hamburg, Germany
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
