[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Behavior of <q> element
Hi, Paul, There are two parts to your objection. I'll respond to the second one first. Quotation marks have exactly the same semantic value as <q> does. They are the conventional plain-text way of tagging a stretch of content (with begin and end tags yet) as material that is quoted. For that reason, this is not rendering in the usual sense, it is substitution of a different notational variant for the same semantic function. This provides a principled demarcation, in answer to your question "where do we stop?". But, you might say, <b>, <i>, and <u> are not just typographic elements (though we call them such), they are notational variants for typographic conventions of bold face, italic, and underscore, with corresponding semantics. The rejoinder here is that they are not notational variants, but rather indeed just typographic rendering, because there are no begin and end tags. In this, I believe that quotation marks are unique. To emphasize the point, note that for <lq> there is no notational variant by this criterion, only rendering as indented text--and that, too, involves a stretch of text uniformly so rendered, with no begin and end tags for the plain text rendition. So, just as the problem does not arise for <lq>, nor does it arise for <b>, <i>, and <u>. The first part of your objection (which you resume in your conclusion) has to do with the separation of content from presentation of content. I believe that is answered above as well. Gershon has pushed a strong form of this with his clients, a requirement never to double-tag quoted material both with typographic quotation-mark tagging and with DITA <q>. I advocated a weaker form, a recommendation not to, with a caveat about consequences if you do. A yet weaker form would be a brief description of the two choices, stating consequences of each. /Bruce > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Tuesday, January 06, 2009 1:37 PM > To: dita > Subject: RE: [dita] Behavior of <q> element > > But the point is that a user cannot do anything about browser > behavior, so it is appropriate for that to be standardized. > > However a user is supposed to be in charge of what style is > applied to their DITA content. A large part of the whole > thrust of SGML/XML and structured content for decades has > been the separation of format (and other application-specific > processing) from the content. > This improves reusability and makes localization easier > (because different uses and locales can apply different > stylesheets to the same content). > > It is wrong for the DITA standard to be standardizing format > or any behavior beyond the basics that make DITA DITA. > > If we start talking about how to format the <q> element, then > where do we stop? I don't see that we need to say anything > here about format in the DITA language reference. > We aren't supposed to be documenting how the toolkit formats > DITA, we're supposed to be writing a specification for how to > create DITA content. > > paul > > > -----Original Message----- > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] > > Sent: Tuesday, 2009 January 06 11:48 > > To: dita > > Subject: RE: [dita] Behavior of <q> element > > > > This could be in the form of a recommendation against additional > > quotation marks, coupled with the observation that if you > do elect to > > add your own quote marks, you must of course not render > <q>...</q> as > > quotation marks, and that there is an overhead cost for > localization > > and portability (one of Gershon's points). > > > > Of course <lq> like <BLOCKQUOTE> shouldn't have this issue, but I > > -have seen people put quotation marks around an indented > paragraph, so > > there could be an educational aspect to this. > > > > The W3C/HTML language has to deal with inconsistent browser > behavior > > (Microsoft is noncompliant until IE-8), whereas we have > inconsistent > > stylesheet behavior to consider. > > > > /BN > > > > > -----Original Message----- > > > From: Grosso, Paul [mailto:pgrosso@ptc.com] > > > Sent: Tuesday, January 06, 2009 10:59 AM > > > To: dita > > > Subject: RE: [dita] Behavior of <q> element > > > > > > I'd rather not say this. It's a style question that may > differ from > > > one house to another as to whether they want to author > the quotes or > > > not and/or how the quote is to be presented. > > > > > > The determination of what text may be generated for a > given element > > > in a given context and/or what other formatting it gets > for a given > > > output (e.g., one may format things differently for PDF > output and > > > HTML > > > output) should be left to the style specification, > however such is > > > provided to a given composition system. > > > This is outside the scope of the DITA specification. > > > > > > So the answer to how <q> should be processed is that it should be > > > processed however its style specification indicates for a given > > > application. > > > > > > paul > > > > > > > -----Original Message----- > > > > From: Robert D Anderson [mailto:robander@us.ibm.com] > > > > Sent: Tuesday, 2009 January 06 9:44 > > > > To: dita > > > > Subject: [dita] Behavior of <q> element > > > > > > > > > > > > Hello, > > > > > > > > Going through the review comments to the specification, I > > > found that > > > > somebody asked for examples of how <q> should be processed. > > > > Generally, we > > > > try to stay away from processing behaviors, but this one > > may be an > > > > exception. The current description gives no suggestions as > > > to whether > > > > or not quotes should be generated. I checked the HTML 4.01 > > > > specification to see what they say; that specification > > says that q > > > > must be rendered with quotations, and that users should not > > > add their > > > > own quotes. > > > > It goes on to > > > > say that the quotes should be rendered in a > > > language-sensitive manner. > > > > See the section on rendering quotations: > > > > http://www.w3.org/TR/REC-html40/struct/text.html#edef-Q > > > > > > > > Should we make a similar statement? I do not want to add > > behaviors > > > > that MUST be done without consulting the full TC, so - > this is my > > > > consultation. > > > > > > > > > --------------------------------------------------------------------- > > > 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_workgr > > > oups.php > > > > > > > > > > > --------------------------------------------------------------------- > > 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_workgr > > oups.php > > > > > > --------------------------------------------------------------------- > 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_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]