OASIS Darwin Information Typing Architecture (DITA) TC

  • 1.  Proposal 13031: Add Line-Through

    Posted 07-26-2011 16:15
    Here are some use cases that I've run into: - Legal documents showing revisions where the revisions are not marked using @rev., - More generally, in a data conversion context where the DITA encoding of the document is not itself being revised, but the content as captured in DITA needs to reflect strikethrough used for an unknowable purpose (at least as far as the agent doing the conversion is concerned). - Discourse where line-through is used for rhetorical effect. - Informal documents, such as business documents, where the overhead of using full revision markup just to get strikethrough is prohibitive (in particular, the need to configure and use some form of DITAVAL facility). Other potential additions to highlight, as distinct from a separate "formatting" domain as represented in DITA for Publishers, include: - overline (as a complement to underline and line-through) - blink (obviously only useful for online presentations). My reasoning for not suggesting more additions to highlight and thus having a separate, more expansive formatting domain, is to make it as easy as possible to not allow formatting requests that most, if not all, technical documentation users would absolutely not want. A separate formatting domain that essentially includes anything that any likely rendition target might support, then provides the option of allowing more where more is appropriate, as it is in most publishing contexts, where arbitrary, distinctive, and idiosyncratic formatting is the order of the day. Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com


  • 2.  Re: [dita] Proposal 13031: Add Line-Through

    Posted 07-26-2011 16:27
    And in the category of legal documents, include standards. I first started thinking about this requirement in the context of the DITA-based GAAP standards developed by the FASB. It also came up at the Federal Reserve, if memory serves. There is a general category of "showing corrections" as well, which is similar to, but not necessarily the same as showing revisions. The fact that something was corrected and what it was corrected from may be an essential part of the content, not simply a revision in the "I changed the file" sense. Cheers, Eliot On 7/26/11 11:14 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote: > Here are some use cases that I've run into: > > - Legal documents showing revisions where the revisions are not marked using > @rev., > > - More generally, in a data conversion context where the DITA encoding of > the document is not itself being revised, but the content as captured in > DITA needs to reflect strikethrough used for an unknowable purpose (at least > as far as the agent doing the conversion is concerned). > > - Discourse where line-through is used for rhetorical effect. > > - Informal documents, such as business documents, where the overhead of > using full revision markup just to get strikethrough is prohibitive (in > particular, the need to configure and use some form of DITAVAL facility). > > Other potential additions to highlight, as distinct from a separate > "formatting" domain as represented in DITA for Publishers, include: > > - overline (as a complement to underline and line-through) > - blink (obviously only useful for online presentations). > > My reasoning for not suggesting more additions to highlight and thus having > a separate, more expansive formatting domain, is to make it as easy as > possible to not allow formatting requests that most, if not all, technical > documentation users would absolutely not want. > > A separate formatting domain that essentially includes anything that any > likely rendition target might support, then provides the option of allowing > more where more is appropriate, as it is in most publishing contexts, where > arbitrary, distinctive, and idiosyncratic formatting is the order of the > day. > > Cheers, > > Eliot > > -- > Eliot Kimber > Senior Solutions Architect > "Bringing Strategy, Content, and Technology Together" > Main: 512.554.9368 > www.reallysi.com > www.rsuitecms.com > > > --------------------------------------------------------------------- > 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 > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com


  • 3.  Re: [dita] Proposal 13031: Add Line-Through

    Posted 07-26-2011 17:39
    I'm concerned that we're straying into a gray area with some of this discussion about strike through. Even though I'm a "strict constructionist" when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate. However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup. Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element. My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup). Best Regards, Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net hamilton@xmlpress.net


  • 4.  Re: [dita] Proposal 13031: Add Line-Through

    Posted 07-26-2011 20:22
    Hi, I'm with Richard in not liking the idea of tying 'strikethrough' to revision/change tracking.  However we decide to semantically describe change tracking, I don't want to prescribe how someone has to present those semantics, even if the DITA-OT makes choices in its processing. I looked at Eliot's list of 'formatting' additions and in addition to strikethrough, I also find the following to be compelling additions to the highlighting domain: -  overline  (heavily used, btw,  in semiconductor documentation) -  bold italic -  roman - removal of bold and/or italic My reasoning is that these are all, like most of the other highlighting elements, glyph-based but not typeface-based presentation (don't get me started on <tt>, but I know it's historical and can't be avoided.).  If we put these items anywhere except hi-d, it will be very counter-intuitive for people looking for such things.  I would favor adding them to hi-d, creating a constraint module to remove them, and including the constraint module by default in all the vocabulary modules calling hi-d, the way we do with the strictTaskbodyConstraint in tasks for 1.2. I don't consider any of the other items in the formatting group to fall naturally into the same category.  Even though blink does meet the glyph-based/non-typeface-based model, and could probably be construed as 'highlighting' in some sense, it doesn't feel like the same thing. my $.02 Nancy On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton < hamilton@xmlpress.net > wrote: I'm concerned that we're straying into a gray area with some of this discussion about strike through. Even though I'm a "strict constructionist" when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate. However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup. Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element. My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup). Best Regards, Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net hamilton@xmlpress.net --------------------------------------------------------------------- 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 -- _____________ Nancy Harrison Infobridge Solutions  nharrison@infobridge-solutions.com


  • 5.  RE: [dita] Proposal 13031: Add Line-Through

    Posted 07-27-2011 16:42
      |   view attached
    I’ll add my “nay” to this idea as well. The “strikethrough” proposal is more a request for a formatting style than a prescription for semantic change. I’d be much happier if the idea called for a semantically-descriptive element (such as “deleted-content”) rather than a prescriptive approach to how that content should be formatted.   As an example of this, we use DeltaXML to help us track changes between documents, and instead of using strikethrough, we use CSS-type changebars in the margin of the text to single out where change has occurred. “Strikethrough” would be a very poor description of the change in content.     The only instance that Elliot lists that doesn’t quite fit with the rest is the instance of “rhetorical strikethrough”. Thing is, I have never seen that used in any technical documentation, only in non-technical articles. If that is truly needed, then something suitably descriptive, like “rhetorical-deletion” would be more semantically descriptive.   I also agree with Nancy on her points, and I can confirm that overline has a special meaning in semiconductor/electrical engineering content, where it typically means a negative value of the same term without the overline.   8-{)}   Keith Schengili-Roberts Manager Graphics Platform Documentation & Localization (Markham) AMD o. 905-882-2600 x3218 Please consider the environment before printing this e-mail     From: Nancy Harrison [mailto:nancylph@gmail.com] Sent: Tuesday, July 26, 2011 4:22 PM To: Richard Hamilton Cc: dita Subject: Re: [dita] Proposal 13031: Add Line-Through   Hi, I'm with Richard in not liking the idea of tying 'strikethrough' to revision/change tracking.  However we decide to semantically describe change tracking, I don't want to prescribe how someone has to present those semantics, even if the DITA-OT makes choices in its processing. I looked at Eliot's list of 'formatting' additions and in addition to strikethrough, I also find the following to be compelling additions to the highlighting domain: -  overline  (heavily used, btw,  in semiconductor documentation) -  bold italic -  roman - removal of bold and/or italic My reasoning is that these are all, like most of the other highlighting elements, glyph-based but not typeface-based presentation (don't get me started on <tt>, but I know it's historical and can't be avoided.).  If we put these items anywhere except hi-d, it will be very counter-intuitive for people looking for such things.  I would favor adding them to hi-d, creating a constraint module to remove them, and including the constraint module by default in all the vocabulary modules calling hi-d, the way we do with the strictTaskbodyConstraint in tasks for 1.2. I don't consider any of the other items in the formatting group to fall naturally into the same category.  Even though blink does meet the glyph-based/non-typeface-based model, and could probably be construed as 'highlighting' in some sense, it doesn't feel like the same thing. my $.02 Nancy On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton < hamilton@xmlpress.net > wrote: I'm concerned that we're straying into a gray area with some of this discussion about strike through. Even though I'm a "strict constructionist" when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate. However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup. Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element. My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup). Best Regards, Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net hamilton@xmlpress.net --------------------------------------------------------------------- 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 -- _____________ Nancy Harrison Infobridge Solutions  nharrison@infobridge-solutions.com


  • 6.  RE: [dita] Proposal 13031: Add Line-Through

    Posted 07-27-2011 17:06
      |   view attached
    I'm not sure what "this idea" (to which you are naying) is, but since you say "as well", and I'm not sure that Nancy was naying the actual proposal (Proposal 13031: Add Line-Through)--in fact, I hear her saying that she doesn't like tying strikethrough to change tracking, and Dick says there is no more connection between strikethrough and revision markup than there is between italics and the <var> element--and I know I wasn't, I thought we'd better clarify.   While I am generally on the side of semantics and separating style from content, is it not the case that strikethrough is equivalent to deleted-content.  In fact, I would be opposed to defining something semantic like deleted-content to imply any particular formatting (such a strike-through), so I don't see how a semantically descriptive element would satisfy Eliot's requirements at all.   The highlight domain isn't supposed to be semantic--it's for highlighting.  True, any non-semantic markup can be misused when there is a more semantic markup that should be used, but tag abuse is even more likely (and more confusing when it occurs) when you don't give users a non-semantic way to get what they want and they have to use positively misleading markup instead of just non-semantic markup.   paul     From: Schengili-Roberts, Keith [mailto:Keith.Schengili-Roberts@amd.com] Sent: Wednesday, 2011 July 27 11:40 To: Nancy Harrison; Richard Hamilton Cc: dita Subject: RE: [dita] Proposal 13031: Add Line-Through   I’ll add my “nay” to this idea as well. The “strikethrough” proposal is more a request for a formatting style than a prescription for semantic change. I’d be much happier if the idea called for a semantically-descriptive element (such as “deleted-content”) rather than a prescriptive approach to how that content should be formatted.   As an example of this, we use DeltaXML to help us track changes between documents, and instead of using strikethrough, we use CSS-type changebars in the margin of the text to single out where change has occurred. “Strikethrough” would be a very poor description of the change in content.     The only instance that Elliot lists that doesn’t quite fit with the rest is the instance of “rhetorical strikethrough”. Thing is, I have never seen that used in any technical documentation, only in non-technical articles. If that is truly needed, then something suitably descriptive, like “rhetorical-deletion” would be more semantically descriptive.   I also agree with Nancy on her points, and I can confirm that overline has a special meaning in semiconductor/electrical engineering content, where it typically means a negative value of the same term without the overline.   8-{)}   Keith Schengili-Roberts Manager Graphics Platform Documentation & Localization (Markham) AMD o. 905-882-2600 x3218 Please consider the environment before printing this e-mail       From: Nancy Harrison [mailto:nancylph@gmail.com] Sent: Tuesday, July 26, 2011 4:22 PM To: Richard Hamilton Cc: dita Subject: Re: [dita] Proposal 13031: Add Line-Through   Hi, I'm with Richard in not liking the idea of tying 'strikethrough' to revision/change tracking.  However we decide to semantically describe change tracking, I don't want to prescribe how someone has to present those semantics, even if the DITA-OT makes choices in its processing. I looked at Eliot's list of 'formatting' additions and in addition to strikethrough, I also find the following to be compelling additions to the highlighting domain: -  overline  (heavily used, btw,  in semiconductor documentation) -  bold italic -  roman - removal of bold and/or italic My reasoning is that these are all, like most of the other highlighting elements, glyph-based but not typeface-based presentation (don't get me started on <tt>, but I know it's historical and can't be avoided.).  If we put these items anywhere except hi-d, it will be very counter-intuitive for people looking for such things.  I would favor adding them to hi-d, creating a constraint module to remove them, and including the constraint module by default in all the vocabulary modules calling hi-d, the way we do with the strictTaskbodyConstraint in tasks for 1.2. I don't consider any of the other items in the formatting group to fall naturally into the same category.  Even though blink does meet the glyph-based/non-typeface-based model, and could probably be construed as 'highlighting' in some sense, it doesn't feel like the same thing. my $.02 Nancy On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton < hamilton@xmlpress.net > wrote: I'm concerned that we're straying into a gray area with some of this discussion about strike through. Even though I'm a "strict constructionist" when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate. However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup. Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element. My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup). Best Regards, Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net hamilton@xmlpress.net --------------------------------------------------------------------- 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 -- _____________ Nancy Harrison Infobridge Solutions  nharrison@infobridge-solutions.com


  • 7.  Re: [dita] Proposal 13031: Add Line-Through

    Posted 07-27-2011 17:55
    I base my view on line-through on the primary use case of migration, both of content and of user expectations coming from a mainly HTML/word processor world view. For other elements in the highlighting domain, the names correspond exactly to incoming names rather than semantic names because it is impossible in most cases to second-guess the author's intent. One principle of migration is that it is better to name something in a way that can be searched and filtered later than to wrongly name something semantically on import because in this case, the content usually *behaves* correctly but the misuse is hiding in plain sight, seemingly already correct. Italicized content is usually among the hardest to guess at algorithmically given the many allowed meanings in guides like MLA (for titles, emphasis, foreign words, special terms, and alternative to underlines, etc.). And while many instances of strike-throughs may be rhetorical, I can't say that all of them are. So I'm inclined to leave the highlighting domain focused on preserving legacy notation whenever the intent is algorithmically unfathomable, which justifies the use of tt and strike-through (which in my experience is more common than line-through ) as commonly used names for those notations. In deference to the work of the TechComm SC in defining best practices specfically for their audiences, I'd suggest that one of their work products ought to be (if not already booked) the creation of a semantic phrase domain per MLA and other broad writing guidelines that parallels the highlighting domain but codifies the usage in appropriate ways for those who adamantly shun the vernacular variety. The Typographic Conventions topic in most tech manuals is precisely the semantic to visual mapping described by various semantic domains including programming and hardware (ie, overbars for flags, which I conceive as specializations of <state> rather than as phrase content). I was just tempted to put a smiley emoticon there but realized that we might just need a domain for those as well. <smile type= devilish /> -- Don R. Day DITA and XML Consultant , 512 244-2868 Co-Chair, OASIS DITA Technical Committee Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? --T.S. Eliot On 7/27/2011 11:39 AM, Schengili-Roberts, Keith wrote: 2897F9A373D2544D997C17EDA4B4D7BA2E5A2A1D03@STOREXMBP01.amd.com type= cite > I’ll add my “nay” to this idea as well. The “strikethrough” proposal is more a request for a formatting style than a prescription for semantic change. I’d be much happier if the idea called for a semantically-descriptive element (such as “deleted-content”) rather than a prescriptive approach to how that content should be formatted.   As an example of this, we use DeltaXML to help us track changes between documents, and instead of using strikethrough, we use CSS-type changebars in the margin of the text to single out where change has occurred. “Strikethrough” would be a very poor description of the change in content.     The only instance that Elliot lists that doesn’t quite fit with the rest is the instance of “rhetorical strikethrough”. Thing is, I have never seen that used in any technical documentation, only in non-technical articles. If that is truly needed, then something suitably descriptive, like “rhetorical-deletion” would be more semantically descriptive.   I also agree with Nancy on her points, and I can confirm that overline has a special meaning in semiconductor/electrical engineering content, where it typically means a negative value of the same term without the overline.   8-{)}   Keith Schengili-Roberts Manager Graphics Platform Documentation & Localization (Markham) AMD o. 905-882-2600 x3218 Please consider the environment before printing this e-mail     From: Nancy Harrison [ mailto:nancylph@gmail.com ] Sent: Tuesday, July 26, 2011 4:22 PM To: Richard Hamilton Cc: dita Subject: Re: [dita] Proposal 13031: Add Line-Through   Hi, I'm with Richard in not liking the idea of tying 'strikethrough' to revision/change tracking.  However we decide to semantically describe change tracking, I don't want to prescribe how someone has to present those semantics, even if the DITA-OT makes choices in its processing. I looked at Eliot's list of 'formatting' additions and in addition to strikethrough, I also find the following to be compelling additions to the highlighting domain: -  overline  (heavily used, btw,  in semiconductor documentation) -  bold italic -  roman - removal of bold and/or italic My reasoning is that these are all, like most of the other highlighting elements, glyph-based but not typeface-based presentation (don't get me started on <tt>, but I know it's historical and can't be avoided.).  If we put these items anywhere except hi-d, it will be very counter-intuitive for people looking for such things.  I would favor adding them to hi-d, creating a constraint module to remove them, and including the constraint module by default in all the vocabulary modules calling hi-d, the way we do with the strictTaskbodyConstraint in tasks for 1.2. I don't consider any of the other items in the formatting group to fall naturally into the same category.  Even though blink does meet the glyph-based/non-typeface-based model, and could probably be construed as 'highlighting' in some sense, it doesn't feel like the same thing. my $.02 Nancy On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton < hamilton@xmlpress.net > wrote: I'm concerned that we're straying into a gray area with some of this discussion about strike through. Even though I'm a strict constructionist when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate. However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup. Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element. My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup). Best Regards, Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net hamilton@xmlpress.net --------------------------------------------------------------------- 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 -- _____________ Nancy Harrison Infobridge Solutions  nharrison@infobridge-solutions.com


  • 8.  Re: [dita] Proposal 13031: Add Line-Through

    Posted 07-28-2011 12:18
    I'm on the fence when it comes to strike-through -- but if we do it, I do think it belongs in the hi-d alongside <b> and <i>. In hi-d, we can call it what it is and avoid confusion that's likely to result if we don't. To Don's point, folks converting content from tools that include change tracking, this would allow them to preserve that change markup at the formatting level when converting from their legacy format to DITA. In case the TC at large is not aware, the Tech Comm SC plans to work on markup for change tracking. I don't see that effort in any way interfering with the request to add line-through (or strike-though, as it's often referred to), or vice-versa. Cheers, Gershon On Jul 27, 2011, at 8:54 PM, Don Day (LbyW) wrote: I base my view on line-through on the primary use case of migration, both of content and of user expectations coming from a mainly HTML/word processor world view. For other elements in the highlighting domain, the names correspond exactly to incoming names rather than semantic names because it is impossible in most cases to second-guess the author's intent. One principle of migration is that it is better to name something in a way that can be searched and filtered later than to wrongly name something semantically on import because in this case, the content usually *behaves* correctly but the misuse is hiding in plain sight, seemingly already correct. Italicized content is usually among the hardest to guess at algorithmically given the many allowed meanings in guides like MLA (for titles, emphasis, foreign words, special terms, and alternative to underlines, etc.). And while many instances of strike-throughs may be rhetorical, I can't say that all of them are. So I'm inclined to leave the highlighting domain focused on preserving legacy notation whenever the intent is algorithmically unfathomable, which justifies the use of tt and strike-through (which in my experience is more common than line-through ) as commonly used names for those notations. In deference to the work of the TechComm SC in defining best practices specfically for their audiences, I'd suggest that one of their work products ought to be (if not already booked) the creation of a semantic phrase domain per MLA and other broad writing guidelines that parallels the highlighting domain but codifies the usage in appropriate ways for those who adamantly shun the vernacular variety. The Typographic Conventions topic in most tech manuals is precisely the semantic to visual mapping described by various semantic domains including programming and hardware (ie, overbars for flags, which I conceive as specializations of <state> rather than as phrase content). I was just tempted to put a smiley emoticon there but realized that we might just need a domain for those as well. <smile type= devilish /> -- Don R. Day DITA and XML Consultant , 512 244-2868 Co-Chair, OASIS DITA Technical Committee Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? --T.S. Eliot On 7/27/2011 11:39 AM, Schengili-Roberts, Keith wrote: 2897F9A373D2544D997C17EDA4B4D7BA2E5A2A1D03@STOREXMBP01.amd.com type= cite > I?ll add my ?nay? to this idea as well. The ?strikethrough? proposal is more a request for a formatting style than a prescription for semantic change. I?d be much happier if the idea called for a semantically-descriptive element (such as ?deleted-content?) rather than a prescriptive approach to how that content should be formatted.   As an example of this, we use DeltaXML to help us track changes between documents, and instead of using strikethrough, we use CSS-type changebars in the margin of the text to single out where change has occurred. ?Strikethrough? would be a very poor description of the change in content.     The only instance that Elliot lists that doesn?t quite fit with the rest is the instance of ?rhetorical strikethrough?. Thing is, I have never seen that used in any technical documentation, only in non-technical articles. If that is truly needed, then something suitably descriptive, like ?rhetorical-deletion? would be more semantically descriptive.   I also agree with Nancy on her points, and I can confirm that overline has a special meaning in semiconductor/electrical engineering content, where it typically means a negative value of the same term without the overline.   8-{)}   Keith Schengili-Roberts Manager Graphics Platform Documentation & Localization (Markham) AMD o. 905-882-2600 x3218 <Mail Attachment.jpeg> <Mail Attachment.png> Please consider the environment before printing this e-mail     From: Nancy Harrison [ mailto:nancylph@gmail.com ] Sent: Tuesday, July 26, 2011 4:22 PM To: Richard Hamilton Cc: dita Subject: Re: [dita] Proposal 13031: Add Line-Through   Hi, I'm with Richard in not liking the idea of tying 'strikethrough' to revision/change tracking.  However we decide to semantically describe change tracking, I don't want to prescribe how someone has to present those semantics, even if the DITA-OT makes choices in its processing. I looked at Eliot's list of 'formatting' additions and in addition to strikethrough, I also find the following to be compelling additions to the highlighting domain: -  overline  (heavily used, btw,  in semiconductor documentation) -  bold italic -  roman - removal of bold and/or italic My reasoning is that these are all, like most of the other highlighting elements, glyph-based but not typeface-based presentation (don't get me started on <tt>, but I know it's historical and can't be avoided.).  If we put these items anywhere except hi-d, it will be very counter-intuitive for people looking for such things.  I would favor adding them to hi-d, creating a constraint module to remove them, and including the constraint module by default in all the vocabulary modules calling hi-d, the way we do with the strictTaskbodyConstraint in tasks for 1.2. I don't consider any of the other items in the formatting group to fall naturally into the same category.  Even though blink does meet the glyph-based/non-typeface-based model, and could probably be construed as 'highlighting' in some sense, it doesn't feel like the same thing. my $.02 Nancy On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton < hamilton@xmlpress.net > wrote: I'm concerned that we're straying into a gray area with some of this discussion about strike through. Even though I'm a strict constructionist when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate. However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup. Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element. My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup). Best Regards, Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net hamilton@xmlpress.net --------------------------------------------------------------------- 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 -- _____________ Nancy Harrison Infobridge Solutions  nharrison@infobridge-solutions.com


  • 9.  RE: [dita] Proposal 13031: Add Line-Through

    Posted 07-26-2011 17:18
    >