OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-adoption message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Thanks Paul. I've started this document. Feel free to add, edit and/or comment: http://wiki.oasis-open.org/dita-adoption/DITA%201.2%20Elements%20which%20Need%20Styling#preview

Beyond the issue of wanting to encourage standard cross-vendor practices, I'm hoping that this article will serve as a nudge so that reasonable DITA 1.2 stylesheets get developed at all. The attached HTML file shows how the attached DITA glossary file looks when it's processed using fallback styling. This won't inspire anyone to use the new elements. Conversely, if you show someone a demo that includes output through a decent processor and stylesheet, they understand what it's all about right away.

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/




-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Thursday, August 05, 2010 6:52 AM
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: Wednesday, 2010 August 04 20:46
> To: Grosso, Paul; DITA Adoption TC
> Subject: RE: [dita-adoption] FW: [dita] DITA 1.2 elements needing
> styling and translatable strings
> 
> 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?

If phrased as a best-practice explanation of the intended use of 
new DITA 1.2 elements, I'd have no problem with us producing such 
a document.

paul

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


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

Title: USB flash drive

USB flash drive

A small portable drive.
Note: Do not provide in upper case (as in "USB Flash Drive") because that suggests a trademark.

UFD

Note: Explain the acronym on first occurrence.

memory stick

Note: This is a colloquial term.

stick

Note: This is too colloquial.
memory stick

flash

Note: This short form is ambiguous.
<?xml version="1.0"?>
<!DOCTYPE glossentry PUBLIC "-//OASIS//DTD DITA Glossary Entry//EN" "glossentry.dtd">
<glossentry id="usbfd"> 
  <glossterm>USB flash drive
  </glossterm> 
  <glossdef>A small portable drive.</glossdef> <glossBody>
  <glossPartOfSpeech value="noun"/> <glossUsage>Do not provide in upper case (as
  in "USB Flash Drive") because that suggests a trademark.</glossUsage> 
  <glossAlt id="glossAlt_1588C45D28784FEA9D7DBF0ED965EFBA"> 
  <glossAcronym>UFD</glossAcronym> <glossUsage>Explain the acronym on first
  occurrence.</glossUsage> </glossAlt> <glossAlt id="memoryStick"> 
  <glossSynonym>memory stick</glossSynonym> <glossUsage>This is a colloquial
  term.</glossUsage> </glossAlt> 
  <glossAlt id="glossAlt_91A692F14C024112970C3FEA66CBC0BE"> 
  <glossAbbreviation>stick</glossAbbreviation> <glossStatus value="prohibited"/> 
  <glossUsage>This is too colloquial.</glossUsage>
  <glossAlternateFor href="#usbfd/memoryStick"/> </glossAlt> 
  <glossAlt id="glossAlt_2DB87901CB2E4322A41BE3B4E04F66D7"> 
  <glossAbbreviation>flash</glossAbbreviation> <glossStatus value="prohibited"/> 
  <glossUsage>This short form is ambiguous.</glossUsage> </glossAlt> </glossBody>
  
</glossentry>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]