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: Example of no comment?


Greetings!

Thinking it might be helpful to use concrete examples on the change 
tracking issue, consider the following:

****ODF 1.1****
3.1.11 Print Date and Time

The <meta:print-date> element specifies the date and time when the 
document was last printed.

To conform with [xmlschema-2], the date and time format is 
YYYY-MM-DDThh:mm:ss.

<define name="office-meta-data" combine="choice">
     <element name="meta:print-date">
          <ref name="dateTime"/>
     </element>
</define>

****/ODF 1.1****

****ODF 1.2****
4.3.2.11 <meta:print-date>

The |<meta:print-date>| element specifies the date and time when a 
document was last printed.

The |<meta:print-date>| element is usable with the following element: 
|<office:meta>| 3.2.

The |<meta:print-date>| element has no attributes.

The |<meta:print-date>| element has no child elements.

The |<meta:print-date>| element has content of data type |dateTime| 18.2.

****/ODF 1.2****

The final four lines in ODF 1.2 are automatically generated from the 
schema.

Summary of changes (that I see, your mileage may vary):

1) Title is different.

2) Change of the definite article "the" (ODF 1.1) to "a"  (ODF 1.2) in 
the first sentence.

3) Schema fragment in ODF 1.1, absent in ODF 1.2.

4) Parent element <office:meta> with link noted in ODF 1.2, absent in 
ODF 1.1.

5) Lack of attributes reported by schema fragment in ODF 1.1, lack of 
attributes reported by auto-generated text in ODF 1.2.

6) Lack of child elements reported by schema fragment in ODF 1.1, lack 
of child elements reported by auto-generated text in ODF 1.2.

7) Final sentence of ODF 1.1 on datatype is omitted. Content datatype 
reported as auto-generated text with link to datatype.

What have I overlooked?

If I were choosing changes to report on ODF 1.1 to ODF 1.2, I would say:

ODF 1.1, 3.1.11, see, ODF 1.2, 4.3.2.11.

One could say that every change should be tracked but realistically that 
is busy work that won't be consulted by anyone. With diffs and change 
tracking we could generate literally thousands of change tracks should 
anyone think that is a useful approach.

Consider the issue I reported in JIRA this morning concerning our use of 
the term "equals." There are 20 some odd instances that need to be 
re-worded. Although those will be tracked by the document change log, I 
don't see any reason to report that on a summary of changes log.

I think what is desired is *not* an automated tracking of all changes 
but rather a considered judgment as to what changes, of all the changes 
made, merit attention by implementers and hence significant enough to 
include in a change log. Those would always include substantive changes, 
often but not always clarifications, and minor grammar issues, probably 
never.

Keying that log to ODF 1.1 is a reasonable request in my view.

I will look for a change to post that I think merits listing in a change 
log.

Hope everyone is at the start of a great week!

Patrick

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