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


Dennis,

Dennis E. Hamilton wrote:
> Patrick,
>
> 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 [;<).
>
>   
Yes, nomenclature is very important. In my world view, "document" is far 
more limited than "text." Text includes everything from cuneiform 
tablets to the illuminated chapters of the Book of Going Forth By Day 
(mis-named the Egyptian Book of the Dead), the carpet pages of the 
Leningrad Codex as well as the more mundane things like presentations 
and other modern ephemera. ;-) OK, ok, I will concede that the 
multi-dimensional aspects of tables, drawings, etc. make them 
interesting as well. But I would subsume all of them under "Text."
> 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.
>
>   
Probably the best way to pin down where it is needed. I guess I was 
reacting to the notion that we would create yet another vocabulary, 
which means we have to imagine the model. What you suggest is that we 
name it as we come across it, if I am reading you correctly. I think 
that works.
> 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.)
>
>   
Well, but I think maintaining consistency is far more difficult that is 
commonly realized. Particularly when we are preparing a document that 
will be used by many people for who English is not their first language.

And even for people whose first language is reportedly English, remember 
that the 811 folks sat in the same room, thought they were using terms 
the same way and went off and implemented different communication 
protocols.
> Maybe we just have to see how it goes?
>   
Sure. Grinding through the text (with a small "t") as in the ODF draft 
is a good starting point.

Hope you are looking forward to a great weekend!

Patrick

>  - Dennis
>
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> http://lists.oasis-open.org/archives/office/200812/msg00101.html
> 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,
>
> Dennis E. Hamilton wrote:
> http://lists.oasis-open.org/archives/office/200812/msg00100.html
>   
>> 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. ;-)
>
> Sorry!
>
> 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." 
> <text:linenumbering-separator>
>
> 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!
>
> Patrick
>   
>>  - 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
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]