Notes on the acronym proposal

["JoAnn Hackos" <joann.hackos@comtech-serv.com>]

Hello Friends,
I've added more notes to Gershon's meeting minutes. Andrzej and Rodolfo
in particular, please review the notes. I've also asked Kara W to review
the entire proposal since she had not yet read it. 

We have two proposals in the notes that we need to consider next week.
Each 
Involves adding a third element to our plan.

Kara's primary concern seems to be with the post-processing for term
extraction. 

I also wonder if that processing could not be revised to account for the
acronym in the expanded form rather than adding complexity to this
proposal.

JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
joannhackos Skype
www.comtech-serv.com


Notes on the Translation Subcommittee meeting of 20070618

Discussion of the Acronym Proposal
//I've added additional comments to Gershon's meeting minutes, JoAnn//

4)  Returning business:
 
    4.1 Vote on the final version of Andrzej and Rodolfo's acronym proposal.

        Kara: Our primary concerns have still not been addressed. The markup is 
        not suitable for downstream processing of the content. Issue is the 
        extended term is part of the term, which gets in the way of extraction.

        Kara suggested to work towards finding a new markup that meets both auto 
        needs as well as translation needs. Putting the long element in the short 
        element because there is no short element will cause downstream processing 
        problems. Rather leave the short element empty, then processing will take 
        the long form.

        JoAnn: Recommendation is when there is no short form, omit the short form 
        element and the long form will be used.//JTH:If the short form is omitted, 
	then the long form must be used.//

	//Language-by-language rules 
	We have tried to avoided creating language-by-language rules because the 
	processing overhead is not trivial. Kara's recommendation would require a
	language-by-language rule.//

        2nd bullet in "Translation Issues": 

            Discussion back and forth...

            Kara suggests 3 elements instead of 2, where the third is for 
            presentation, which incudes the formatting/punctuation etc. and 
            still preserves the short and expanded forms for automated
            processing.

	    //Problem with adding an element is the complexity of the decision-making
		for the transltor. Quality of localization is an issue.//
            
            JoAnn: We can't decide this without Andrzej and Rodolfo. Asked Kara 
            to take a look at the current proposal and consider the suggestion 
            of adding a third element for presentation, or Bruce's suggestion
            of adding an attribute order="short-first | expanded-first" and the 
            idea is to have a default setting for the language and allow the 
            translator to override the default in specific cases by setting this
            attribute value. We need to note that the translator is trying to 
            control the presentation via this attribute (or via the third 
            presentation element).

		//Again here, we are concerned with leaving all of this in the hands
		of the translator. Gershon and Nick both alluded to quality control
		issues.//

        3rd bullet: 
	    //Issue (question for Rodolfo)-- punctuation of the expanded form as 
		the first word in a sentence if 
		no acronym is available. See the Spanish example in the proposal. What would
		happen if this phrase began a sentence. Would there usually/always be an
		article before the first word of the expanded form?//

            Kara: This problem would normally not occur, but may occur in list 
            where you would not normally put an article before the acronym.

	    //Here is Bruce's Note on this issue:
		The <acronym> proposal raises some questions about how to handle 
		linguistic phenomena (articles and capitalization).

		The last use case shows an expanded form for SIDA, the Spanish acronym for AIDS.

		We have no way of indicating whether this is ordinarily preceded by an 
		article (the, or a declined form of it). I don't know whether one is needed.

		Also, the example mentions the difficulty that in Romance languages such as 
		Spanish, the expansion would ordinarily not be capitalized. 
		However, at the beginning of a sentence, it would be. 
		This is a more general problem about conref-ing terminology into a context 
		that requires capitalization.

		As DITA becomes more sophisticated about both terminology and translation, 
		it becomes increasingly tempting to provide support for phenomena 
		such as capitalization. Any capitalization requirements in the context 
		performing a conref might need to be handled in conref processing.


            
	4th issue
	    Bruce and Kara asked to make readers aware that the ID values need 
            to be a unique identifier.

            JoAnn suggested adding a note that there's no mandate for the ID 
            value to match the short term.

            Bruce: We've carefully avoided making language-specific problems. 
            What about the issue when a person wants to conref to the beginning 
            of a sentence?

            ACTION: Bruce to send email to JoAnn about the linguistic issue.