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] Formal Request: ODF 1.2 Document Processing Model Proposal


Some follow-up comments:

1. I'm not thrilled by text model.  It seems too narrow and is only part of the deal (consider tables, drawings, presentations, etc., where a text model is just part of the deal).  I would rather go to document model than text model.  

Question: In you passage '"text" (as distinguished from "document" modeling in the more limited markup sense) modeling', are you thinking of document as more limited.  I intended ODF Document Structure for the (logical) artifact (markup and such) level, as opposed to the abstraction that is somehow conveyed in the document structure.  I mean semantics up-level from XML and markup "semantics."  Maybe that is where we are looking cross-eyed at the same things.  (Another demonstration of why a nomenclature section is important [;<).

2. I agree this is an incremental activity and the idea is not to attempt to define the world.  However, I think we stumble over tacitness and non-groundedness in the specification in ways that are detrimental (as in the tendency to use the spec as a way to fix what is arguably an implementation bug in the presentation:pages situation).  I think as we bear down and review the specification drafts and attempt to address all of the notes you have in them we will demonstrate the need to have some level of this in order to get ourselves out of the woods.

3. As much as my eyes glaze over when I see a nomenclature section in an ISO specification, I think they are indispensible and even critical in the case of ODF.  First, we borrow wholesale from other specifications and they have their technical language (e.g., what an XML document is versus what an ODF document [representation] might be said to be) that is confusing in those parts of ODF where the notions appear to be comingled without discrimination.  Also, the way we talk about notions and semantics from other specifications is troublesome and we need to get clear about that.  In this respect, we do need to be clear what terms of art we are using (and also introducing ourselves).  In that regard, it seems to me:
 - we should make major conceptual definitions in a nomenclature section (and it should be allowed to reference sections where there is more depth and context if needed).  There is nothing wrong with defining many things local to their (confined) use.  ISO documents do not put every specialized term in the nomenclature, but we need to have something that calls forth consistency in major cases.
 - we should make it clear when we are using the notion in the nomenclature and have some way to not confuse that with informal use of phrases having some of the same words (or teach ourselves to use different words).
 - some problems are simply that a common noun is used without sufficient modifiers to maintain context and signal its technical use.  It is a bit wordy to always provide adjectives, but that is the price (along with looking for alternative wordings and terms that minimize the confusion).  The use of "separator" is an example.  
 - for OASIS, our documents (in both ODF and PDF) are really hypertexts and we can take advantage of that to make the relationship between the nomenclature/glossary section and an usage very clear. (I am not proposing that we do that for 1.2, but it seems like a good thing to keep our eye on.  (Apparently ISO or ITTF is not consistent in not preserving that sort of thing in their PDFs, which makes using their versions of IS 29500 parts a real bitch, although IS 26300 does include the TOC linking from the OASIS 1.0ed2 cs1 version.)

Maybe we just have to see how it goes?

 - Dennis

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Thursday, December 11, 2008 12:56
To: dennis.hamilton@acm.org
Cc: 'ODF TC List'
Subject: Re: [office] Formal Request: ODF 1.2 Document Processing Model Proposal


Dennis E. Hamilton wrote:
> Patrick,
> There are already tacit indications of processing assumptions wherever the specification mentions user interaction or suggests behaviors (e.g., default properties recorded for use when a new table row is introduced).  The problem is that these are not grounded in anything.  (Maybe we should remove them.  That is valuable to discuss.)
Ah, well, yes, they are grounded, just not in the explicit text of ODF 
1.2. ;-)


One term we could use would be text model since what I suspect most of 
the semantics we define (at least in the presentation areas) are based 
on an implicit model of texts.

[ ... ]

Having said all that, I have been at the "text" (as distinguished from 
"document" modeling in the more limited markup sense) modeling game for 
a long time and while I can see real value in reaching common 
understandings of some terms and perhaps even defining a handful of 
them, I really don't think the pursuit of a solid model for texts is a 
useful enterprise. The more we press for something definite in one part, 
the more likely something will poke out on the other side, whether we 
see it or not.
> Processing Model might be the wrong term.  I was looking for a single noun phrase.  Off-and, I don't think I would be adverse to Document Model and Semantics, but I am wary of confusion with other uses of Document Model in our field. That would be something to hash out.  
My suggestion is "text model."
[ ... ]
Well, but I see conformance, particularly with semantics as being 
incremental at best. There are some bright line areas, such as font 
size, which has a commonly accepted definition. There are a lot of gray 
areas as well.

[ ... ]

I suppose my caution is to start such a quest with the understanding 
that we really don't have a firm grasp on the semantics of texts and 
that the more we talk about what understandings we do have, the more 
precise they will become. But it is always an iterative process and not 
one that ever finishes. I would like to think that ODF 1.2 is going to 
be another step towards greater clarity in some semantics but realize 
that it will have probably made other worse. Perhaps greater clarity is 
too bold a claim, I would be happy with a different clarity! ;-)

[ ... ]

I really dislike nomenclature clauses, which I note are optional in the 
ISO Directives.

The reason is we have to *repeat* the definitions that already occur 
elsewhere in the standard and those definitions in the nomenclature 
clause *appear without context,* which can make defining some of them 
quite difficult.

Violates the first rule: Never repeat a definition (because it appears 
once in the nomenclature clause and where we use it).

Violates the second rule: Never define a definition differently. That is 
just fraught with peril for mistakes.

Perhaps an unfair example:

I want to define "separator."

Hmmm, how about: "A separator is a character that is displayed in lieu 
of a line number"

Relying on: "A separator is text that is displayed instead of a line 
number for lines where no number is displayed." 

Yeah, but then the style folks say: "But <style:column-sep> says a 
separator is a line between columns."

The context in which I use the term is critical to its definition.

Granted you want to define far more general terms and that is why I said 
the example is unfair, but where do we draw the line?

My preference, subject to the wishes of the TC, is to define terms as we 
encounter them and then to consistently use them. I think that is the 
very strong point that you are making. I am hopeful that with everyone's 
assistance that we will have a high level of consistency in that regard.
> Finally, I agree there are lots of ways to "process" ODF document structures (I am becoming fond of that term), and I don't propose ruling any of them out.  However, there are clearly presumed scenarios around what it all means when the ODF document representation is turned into a perceivable document for human use in office document applications and that the interpretation is in conformance with the semantics for ODF documents.  The challenge is figuring out how any normative language about that occurs in the specification, if at all, and then what it means to say that some (class of processing) is implemented in a conformant way.  
Sure, and that is the very hard part.
> I don't see how we can get by with no semantics at all for the markup (and I don't think you are suggesting that).  The ODF appeals to other standards by reference would seem to bring with them semantics from those specifications in any case.  Or maybe not. With the substitution of OASIS namespaces, I am not entirely clear what is incorporated and what is not. 
No, I am not suggesting that markup has no semantics, just that we need 
to avoid thinking we have been overly precise with those semantics.

And true, we need to be as precise as possible when we import other 
elements what we think the semantics are that we are importing.
> I suppose that the OIC TC can go farther in this direction than the ODF specification might, but if there is no meaningful conformance in the ODF spec, it doesn't give anyone much to go on when it comes to assessing conformance of products, proposing ways to improve assurance of interchange and interoperable use, etc. 
I think we need to look really closely at the work Michael has been 
doing on the conformance clause. I must confess that I have been 
concentrating on other matters but from what I have read he has taken us 
forward on the issues of conformance. As the standards evolves I think 
our understanding of it and what it means to conform to it will evolve 
as well.
> Thanks for your response.  I value this conversation with you.
And I with you! It is a welcome break!

Hope you are having a great day!

>  - Dennis
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> http://lists.oasis-open.org/archives/office/200812/msg00090.html
> Sent: Thursday, December 11, 2008 00:52
> To: dennis.hamilton@acm.org
> Cc: ODF TC List
> Subject: Re: [office] Formal Request: ODF 1.2 Document Processing Model Proposal
> Dennis,
> My puppy woke me up (it is raining in Covington) so I decided to catch 
> the early email. ;-)
> This is an interesting proposal but I could not decide if you were 
> proposing:
> 1) A model and additional text about that model to be added to ODF 1.2 or
> 2) A model that would be used as a heuristic in evaluating the 
> completeness/incompleteness of ODF more generally?
> Moreover, I am not entirely sure that we need to go towards processing 
> models, although they are a critical step in the chain of events that 
> lead to a "document" in the sense of something that we view and share 
> with others.
> The reason why I make that last statement is that I prefer to think of 
> ODF as a format that stores information that obviously has an implied 
> model of a document, <text:h>, <text:p>, etc. but that does not require 
> a particular processing model for the information so recorded. That is 
> to say that I can certainly process an ODF document instance with XML 
> tools, or I can use tools that are completely innocent of XML in terms 
> of their processing of the document (a table based model, for example), 
> so long as when they serialize a result to be saved, they do so in the 
> correct ODF XML structure. And, of course, they honor the semantics that 
> have been defined for some content in the ODF document.
> Having said all that, obviously those sort of distinctions are easy to 
> say in the abstract and hard to enforce in concrete cases.
> Looking forward to hearing more about your proposal.
> Hope you are having a great day!
> Patrick
> Dennis E. Hamilton wrote:
> http://lists.oasis-open.org/archives/office/200812/msg00088.html
>> I formally request consideration of the proposal "ODF 1.2 Document Processing Model" for ODF 1.2
>> The new proposal document with an incomplete sketch is on the wiki at 
>> http://wiki.oasis-open.org/office/ODF_1.2_Document_Processing_Model
> [ ... ]

Patrick Durusau
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)

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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