RE: [dita] Behavior of <q> element

["Grosso, Paul" <pgrosso@ptc.com>]

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 
> 
>