Hi, Dave. Your point is well taken--quotes
and <q>-with-attributes do not have "exactly the same semantic value"
(what I said)--but this does not vitiate the formal distinction of
paired tags vs. stretches of formatted text.
Sounds like you're advocating the weakest
of the three options. (The three were prohibit, recommend against, or present
the choices with their consequences.)
/B
From: David Muir [mailto:]
Sent: Thursday, January 08, 2009 10:58 AM
To: Bruce Nevin
(bnevin)
Cc: dita
Subject: RE: [dita] Behavior of
<q> element
Bruce:
Quotation marks do indeed have the exact same semantic value
as <q>. However, they do not have the same value as, for example <q
id="xxx"> or <q> with any other of the univ-atts supported by the q
element.
I would further argue that if you are talking about processing
an element into a presentation format, any consideration of semantic
equivalency becomes moot anyway. It is a typographic convention (like italics
for titles) that could be broken at any time by maverick graphic designers
like those employed (annoyingly) by Wired magazine.
Having said that, I
think the idea of providing a "rendering examples" section for elements is not
a bad idea -- especially for nested quotations and language specific
considerations. I think it is especially important to warn against source
coding like <q>"what I said"</q>. I would just hesitate to have
the spec follow the W3C lead and include a "must ensure"
statement.
Please note: I am just an observer, not a member of the
TC.
Cheers,
Dave.
"Bruce
Nevin (bnevin)" ---06-01-2009 21:41:18---Hi, Paul,
From:
"Bruce Nevin (bnevin)"
<>
To:
"dita"
<>
Date:
06-01-2009 21:41
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:]
>
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:]
>
> 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:]
>
> > 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:]
>
> > > 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
>
>
---------------------------------------------------------------------
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
