[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
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 [;<). 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] 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) --------------------------------------------------------------------- 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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]