[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Conformance Clauses and NVDL
Patrick, "loosely conforming" may be a bad term, but "level 1 conformance", "level 2 conformance" implies to me that there are different feature sets or the like that an ODF application my implement. That is not the case. There is only the case that a document may include only elements and attributes defined by ODF itself (that is a conforming document), or may contains extensions (that is a strictly conforming document). Anyway, that is just the name. I'm fine with naming the individual conformance types differently if there is a consensus that other names may be more appropriate. What is more important to me at the moment is whether the proposed clauses themselves are okay. Michael On 10/13/08 15:46, Patrick Durusau wrote: > Michael, > > Just a comment on the usage of "loosely." > > If we are going to enumerate in detail conformance (a good idea) then > why not simply name levels/stages of conformance? > > I suppose "loosely" as written serves that function but semantically I > wonder if it carries more baggage than you intend. > > As opposed to stage/level 1 conformance is...., stage/level 2 > conformance is...., etc. > > Hope you are having a great day! > > Patrick > > Michael Brauer - Sun Germany - ham02 - Hamburg wrote: >> 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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]