[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Conformance Clauses and NVDL
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 >>> >> >> > > -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]