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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oiic-formation-discuss] Reference implementation. Layout perfect.

2008/6/16 Hurley, Garry (L&I - OIT) <ghurley@state.pa.us>:

> ******************
> Now, first of all, I want this on record that although I work for a state government agency in Pennsylvania, my comments do not reflect those of the Commonwealth of Pennsylvania, its government agencies, or even the majority of its citizens.  That said, I do have a comment on your post, Dave.  First of all, shouldn't we restrict this discussion to the important matter at hand?  I mean, this is a file format, right?  Open Document FORMAT.

Seems not. People on this list want to address format conformity
(document conformity seems to be
the expression preferred) and application conformity, which may or may
not become something else.
Interop is the end game there I believe.

 I think the first order of business is to describe the way that a
file will be organized, what information will be encoded and how it
will be encoded.

Document conformance. I'm started to review the standard wrt to that.

>  As for displaying on the screen, it is a moot point.  I know that as a state employee, we have to concern ourselves with accessibility issues.  "How does this document 'display' in a screen reader, or a type magnifier?" for example.  To that end, screen shots are largely implementation specific.

I believe that will come out in the wash as a 'profile' if the trends
are followed?
We'll need application profiles for 'aural' presentation as well as others.
There is, however a valid case to be made for visual presentation, variously
described as pixel perfect, layout perfect etc. I personally remain unconvinced
that this is viable other than as something like the format I've cut
from the top
of this post, and which you answered.

> Now, what we need to do is to try to say something like "Okay, we know that we want this type to be in a 24-point Times-New Roman font.  Now, how do we store that information in the file and then read it back to display it properly on screen?"

The issue is in defining 'properly' in a standards oriented,
verifiable way; that works for me on my old x dpi screen
and your new y dpi screen? Not easy.

> As for spreadsheets, we need to specify how to write an equation or a value into a cell, specify its width, height, word-wrap, etc.  We don't need to tell anyone how to implement that on a display screen.  As long as we say "red font color for negative numbers" the individual OS and applications programmers can decide what "red" means.

Agreed in outline. Hardly a verifiable statement Garry?
Some of that can be automated, other parts of it may not be.
Point to a para in the standard and see how you get on.

> Databases have a specification language called SQL.  (Yes, I know that only the Data Definition Language - DDL - portion of SQL can be loosely called a specification.)  That language is pretty much standardized, and some vendors have extensions to it.  Let us not say that no vendor may extend the standard, but rather that no vendor's extensions shall be adopted as the standard without input from the rest of the standards group.

My goal is verifying conformance to ODF, thereafter to called up
standards. Extensions are in the spec (weakly defined)
but present. If they are testable as expressed then we should. Else we
need to report back 'untestable'.

> I only point out these things in light of your ISO 9000 comment.  You see, I did work as an ISO 9001 Internal Auditor for a while at one of my factory jobs.  The way ISO 9000 was explained to me is that we "say what we do and we do what we say".  In other words, let's document what we ARE doing, and stick to it.

Problem. Go read Oasis process document:

This group is defining/documenting what the next group, the TC, should
do? Then they'll have to stick to it.

> To others in the group, I apologize if my comments seem rude, arrogant, or anything but genuine.  I only want to see the discussion stay focused on what I believe to be the primary goal:  to standardize the way documents are exchanged between similar programs.  Correct me if I am wrong, but isn't that what ODF is all about?

np. Fair points, seems like we're going in the same direction.
Nice to see a .gov on board!


Dave Pawson

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]