RE: [oiic-formation-discuss] Deliverable: odf-diff?

["Hurley, Garry \(L&I - OIT\)" <ghurley@state.pa.us>]

-----Original Message-----
From: Sander Marechal [mailto:sander.marechal@tribal-im.com]
Sent: Friday, June 20, 2008 11:24 AM
To: Dave Pawson
Cc: oiic-formation-discuss@lists.oasis-open.org
Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?


Dave Pawson wrote:
> 2008/6/20 Sander Marechal <sander.marechal@tribal-im.com>:
> 
>>> In which case your interpretation of 'different' needs clarity
>>> Sander?
>> Most definitely. I'm a developer, a tech person. I'm not much of a 
>> wordsmith. If I can get my point across then I hope someone else
>> can run with it and write a "proper" definition :-)
> 
> I'm still not clear on your definition/interpretation of 'different'.

Functionally equivalent? The only things that can differ are things that 
the spec implies can be different? I was hoping that my examples would 
make clear what I meant with "different".

*******
More or less, I agree with this statement, Sander.  I think the spec should tell us how to represent a line, perhaps, but the actual drawing should be left to the graphics program.  The spec should tell the programmer how to read the specification file.  For example, "a rectangle is identified by the top, left corner, a width, and a height" would be written as:
<object:rectangle start:x="200" start:y="10" width="75" height="150" /> (as a badly written XML example).
An application would read that XML, decide where on the screen to start, how wide, and how tall the rectangle would be, and draw it depending on other tags not listed here.  All applications would then be required to know that "start:x" was the horrizontal start position, and "start:y" is the vertical start position.  Of course all positions, widths and heights will be relative to the reference frame.  If one drawing pixel equals 15 screen pixels, multiply all numbers by fifteen for scaling.  That would be internal to the application, however, not something we specify in the ODF file.  (That is for the pixel-perfect people - or as I like to call them, the PPP.)
*******
>> You're quite right that metadata changes
>> should show as well. For the load&save example I gave, the only
>> difference between the document should probably be "last edited" or
>> "last saved" or "last edited with application X" fields. To give a
>> better example:
> 
> So that would be the {infoset or something} is the same, except 
> xpathA/text() is different xpathB/@Y is different. etc.

I don't understand you here. Sorry. What I mean was, that an ODF-diff 
tool should report that the "last modified by" field is different. It's 
up to the person running the tool to realize that this field is supposed 
to be different when you load and save a document.

*******
Sander, the tool could be programmed to check for this difference and ignore it IF it was a part of the ODF how the 'last modified by' was reported.  In other words, <metadata name="lastModifiedBy" value="..." /> (assuming XML is the language used in the general specification) would be parsed and ignored.
*******

>> Someone on this list mentioned that an application can rename all
>> of the automatic styles however it feels like when it saves a file.
>> An ODF diff tool should take this into account when comparing the
>> two files.
> 
> Better. *ignore all style(presentation) values* and run an xml diff.
> 
> That would be something like an interchange profile perhaps? Is that
> what you want?

No. If you ignore all style values, two documents would still be the 
same if one document has some word bolded, while the other one does not.

Example 1:
Document A has it's second word bolded and document B not. That's a 
difference that should be reported.


*******
I agree with Example 1 completely.  Such formatting differences should be reported.
*******
Example 2:
Both document A and B have it's second word bolded. The bold style is an 
automatically generated style. In doc A the style name is "foo" and in 
doc B the style name is "bar". But both "foo" and "bar" describe the 
exact same thing (e.g. Default + some fo:font-weight). They are the same 
and ODF-diff should say nothing.
*******
I disagree with your conclusion here Sander.  First of all, if both are to be compliant to the same standard, that actually implies that the style name should be the same.  If, for example, one uses the word 'strong' and the other uses the word 'bold' to mean the same thing, then one is wrong.  In fact, I would lean towards requiring the word 'strong' (to signify a strong emphasis) rather than 'bold' (signifying a type face) to assist in accessibility for the visually impaired.  Conversely, a 'bold' tag on the description of a line or outline is perfectly acceptable.  You see where different names could be interpreted diffently depending upon context.
*******

Example 3:
Same as example 2 but now it's not an automatic style but a manually 
made style. Now the ODF-diff should report it as a difference. After 
all, the syle name was specified by the user and he has (probably) made 
care to pick a certain style name.

*******
This point I agree to, so long as it reflects my concerns about your Example 2.
*******

>> Another example: The order of elements in the manifest.xml doesn't
>> matter. As long as all the files are referenced.
> 
> Ah. You need to check with the spec on that, but that's clear. The
> file list is a set (order unimportant)

It's an example I made up on the spot. I'm not 100% sure the spec says 
anything about the order of referencing images in the manifest, but I 
don't believe it does :-)

 > Who else would it help, who is also a 'customer' of the TCs output?

I thought the TC's output was (umong others) the ODF application 
developers? Other users for this tool are the TC itself. How are you 
ever going to do conformance testing or an ACID test if you can't even 
tell if two ODF documents are the same? Being able to tell if two 
"things" are the same seems to me a pretty basic thing in any 
testing/conformance environment.

My thoughts are that (A) application developers and tookit developers 
could really use such a tool. (B) The TC is most likely going to have to 
develop something like this either as part of one of the other 
deliverables or just to internally test whatever they're writing and 
developing. For example, as part of the set of atomic feature test 
documents. (C) It's very hard to go through the spec and build such 
tool. It requires intimate knowledge of the spec. Since the TC is most 
likely going to do the leg-work for this anyway (see B) we may as well 
put it on the list of deliverables so that everyone can profit it.

-- 
Sander Marechal

---------------------------------------------------------------------
To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org


*******
Sander,

I am reluctant to assign the role of developer to the TC in addition to approving the standards.  I have looked at my boss's face when he comes out of one meeting and has enough time to catch his breath before heading into four more back-to-back meetings to do development planning.  Then in his spare time, he is supposed to write my performance report (and the reports of about ten other developers), interview prospective developers for positions that become available, direct the work of the eleven developers under him, and when I, or someone else has to stay late for some reason, he has to stay, too.  I swear that in the past year, he has aged five years.  In other words, let's just ask the TC to spec out a test tool, and let the development to developers who do not represent the 'big three' out there.  This gives us quite a few benefits.  First, it frees the TC's time to concentrate on the specs and not be burdened with actual coding, which arguably may not be their strongest suit.  Second, it allows someone other than 'the big three' to be involved in the outcome of the standards process.  Oh, and by the way, the 'big three' I refer to are IBM, Microsoft and Sun, just for those of you who didn't guess.  Third, since we have separated the test tool from the software being evaluated, the tool becomes harder to manipulate (like programming the application so that it passes the test, but not everything documents do passes the standards).  Fourth, it quiets insistence that the TC is being one-sided in its approach and ignoring interoperability.

Garry L. Hurley Jr.
Application Developer 2
Office of Information Technology - Bureau of Application Development
PA Department of Labor & Industry
651 Boas Street, Harrisburg, PA 17121 
Phone: 717.506.9373 (UCMS) or 717.346.9799 (Harrisburg)  Fax: 717.506.0798  Mobile: 717.649.0597
www.dli.state.pa.us <http://www.dli.state.pa.us>


My comments do not reflect those of the Commonwealth of Pennsylvania, its various agencies and departments, or its citizens.  They are my own, and may or may not be shared by those in positions of authority over me.