OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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