RE: [dita-adoption] FW: [dita] DITA 1.2 elements needing styling and translatable strings

["Su-Laine Yeo" <su-laine.yeo@justsystems.com>]

I think we are converging. I take your point about the stylesheet, rather than the processor, determining which elements should be displayed with strings. The reason I referred to processors rather than stylesheets is that people often use and customize the stylesheets that come as part of the processor. To be more accurate, we are talking about recommendations for stylesheet developers rather than processor developers. 

What I'm trying to produce is something very simple. I just want to be able to give stylesheet developers a list of elements and say, "here are the new elements and attributes for which we recommend you insert generated text, and here are some other elements you might want to pay attention to as well, because the default class-based styling probably won't meet expectations." Although not directly aimed at writers, writers would be able to figure out what it means for them. Can we produce this type of document?

Regards,
Su-Laine


-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Tuesday, August 03, 2010 4:23 PM
To: DITA Adoption TC
Subject: RE: [dita-adoption] FW: [dita] DITA 1.2 elements needing styling and translatable strings


> -----Original Message-----
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Tuesday, 2010 August 03 18:03
> To: Grosso, Paul; DITA Adoption TC
> Subject: RE: [dita-adoption] FW: [dita] DITA 1.2 elements needing
> styling and translatable strings
> 
> I think it's in the interests of the DITA community to have practical
> consensus on which elements should be displayed with strings that are
> inserted by the processor. For example, if processors don't insert text
> such as "Skill level: " for the <perskill> element, then many writers
> will write "Skill level: " into their content to make it appear in
> output, which is fine until you have a processor that *does*
> automatically insert this text into the element.

I don't know what you mean by "processor".  In my world view,
generated text (aka inserted strings) are specified by a
style sheet under user control, and processors insert strings
depending on what the user's style sheet says.  It's not 
something we can dictate.

We could write a best practices that says, for example, that
one should not put anything like "skill level" into one's
content, but should rather style the <perskill> element so
that is generates the appropriate string.

> 
> I don't object to the Adoption TC writing a paper that discusses
> element semantics without making styling recommendations, however I
> don't  have anything to contribute about this subject beyond what the
> official language reference already says. If we want to produce such a
> document, someone else would have to volunteer to write it.
> 
> W.r.t. process, the DITA TC gave me an action item this morning to
> submit the email below to the Adoption TC for our consideration. It is
> of course up to the Adoption TC to decide what we want to do with the
> idea, regardless of what the DITA TC thinks.

I completely agree--I hope my previous email didn't make it sound
like I thought otherwise.  Since not everyone on the Adoption TC
is on the DITA TC, I just wanted to clarify that the DITA TC was
not necessarily "comfortable with producing a document containing
recommendations on how to style new DITA 1.2 elements" because we
did not have that discussion.

paul

> 
> Best,
> Su-Laine
> 
> 
> 
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Tuesday, August 03, 2010 1:20 PM
> To: DITA Adoption TC
> Subject: RE: [dita-adoption] FW: [dita] DITA 1.2 elements needing
> styling and translatable strings
> 
> We need to discuss this.  I'm generally not comfortable with
> recommending how to style elements (and the DITA TC did not endorse us
> doing so this morning, it just said this issue wasn't one for the DITA
> TC).
> 
> It might be appropriate for the DITA Adoption TC to write a paper about
> how new DITA 1.2 elements could be used which might touch on possible
> styling, but we need to stop short of "recommended styling".
> 
> paul
> 
> 
> 
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Tuesday, 2010 August 03 15:05
> To: DITA Adoption TC
> Subject: [dita-adoption] FW: [dita] DITA 1.2 elements needing styling
> and translatable strings
> 
> Hello,
> 
> The DITA TC discussed this issue this morning, and concluded that it
> falls more under the mandate of the Adoption TC.
> 
> Is the Adoption TC comfortable with producing a document containing
> recommendations on how to style new DITA 1.2 elements? And if yes, does
> anyone have a draft that can be used as a basis for the document? I
> could probably come up with a draft if needed.
> 
> Cheers,
> Su-Laine
> 
> 
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 778-327-6356
> syeo@justsystems.com
> www.justsystems.com
> XMetaL Community Forums: http://forums.xmetal.com/
> 
> 
> 
> 
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Friday, July 30, 2010 6:43 PM
> To: dita@lists.oasis-open.org
> Subject: [dita] DITA 1.2 elements needing styling and translatable
> strings
> 
> Hi everyone,
> Is there a list of new DITA elements and attributes for which
> processors are expected to apply special styling and/or generated text?
> For example, the new <note="warning"> attribute needs a new string
> which needs to be translated. It seems that many of the new elements
> for Learning & Training and Machine Industry also warrant some kind of
> distinctive appearance, otherwise adopters will wonder why they are
> bothering to use them.
> Who is responsible for coming up with this list - the DITA TC , the
> DITA Adoption TC, or each team that develops a DITA processor?
> Su-Laine
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 778-327-6356
> syeo@justsystems.com
> www.justsystems.com
> XMetaL Community Forums: http://forums.xmetal.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