Re: [xtm-wg] Re : Style Guide for XTM specs

[Murray Altheim <murray.altheim@eng.sun.com>]

Bernard Vatant wrote:
> 
> Sam, and other brave editors
> 
> A general practical suggestion for editing prose style.
> 
> The main difficulty is the constant mix-up of technical terms defined in
> the spec and used in the syntax, and meta-terms, often very close to and/or
> identical/synonymous of the previous ones. That is we have a constant
> mix-up of language and meta-language, the first one being itself as much
> and maybe more "meta" than the second,  and hence the risk that only
> veteran topic map hackers will see which is which ... and so much for the
> external communication, promotion and marketing.

I agree entirely on the complexity of communicating in one language, much
less in many. We do have problems in our current usage that must be fixed,
but I must respectfully disagree on the solution you propose, which relies
too much on font formatting.
 
> So, for the reader (and writer) to be able to make the distinction, the
> spec terms should be typed in a characteristic {style} like bold red or
> italic blue or something, in a coherent way all along. Any word not in that
> style is "meta", even if the same words are used at both level, which is
> bound to occur with e.g. "names" or "subjects" , even if it should be good
> to avoid it for clarity of discourse. Keeping the *meta* vocabulary to the
> minimum core is a *meta* guideline. That's the only way : stick to the
> concise, clear and absolutely boring style of good maths litterature.

While this may be helpful (and is already done to a great degree in the
current online specs), it is problematic for accessibility (ie., use by
those unable to discern color or font differences), and spec interoperability,
since some browsers do not correctly support all font differentiation (though
most do some), but almost all of this is lost in printing. Color simply 
should not carry important meaning in a text. Hints only. Many people have
difficulty differentiating font family differences as well, though this is
somewhat more reliable than color. As mentioned, we already use font and
color to some degree, but we shouldn't *rely* on it for meaning.

> Such a guideline would be particularly useful when translating the spec
> into other languages, like French (au hasard). The spec terms will not be
> translated, of course, only the meta prose, since the patiently built
> english terminology - which is not only a terminology, but an ontology -
> will find no exact match in any foreign language or culture, which means
> not only the syntactic terms are of course non-translatable for obvious
> technical reasons, but the spec users will have to "build knowledge" about
> it, by understanding what is the *subject* of every *element* in the
> specification. And my hunch is this knowledge is somehow deeply rooted in
> the original language and cultural background of the spec authors, and not
> as universal, intuitive, and straightforward in any other
> linguistic/cultural background that some would think to begin with. Users
> will have to learn what "association" or "subject" means, the same way
> maths students learn what "vector" or "mapping" means.

I'm discussing with Sam the idea of creating some custom markup and an
XSLT stylesheet that would translate it into XHTML. Our big problem is lack
of time to create tools. There are very few working days between now and
mid-January to test out unknown processes. The last one was simply a crunch
to get done on time, and none of us have much time to spare in development 
of processes. Seems a classic IT problem...
 
> For example, the French for Topic is "Sujet", and the French for Subject is
> "Sujet" ...  (çà commence mal !). So we'll have to keep "Topic" in red bold
> in French prose, such as in the following excerpt ( *underlined terms*
> should be red bold )
> 
> [ In the example below, *scope* is used to differentiate the *base names*
> of the *topic* "Hamlet" (the play) from "Hamlet" (the character)]
> 
> Would translate in French :
> 
> [Dans l'exemple ci-dessous, *scope* est utilisé pour différencier les *base
> names* du *topic* "Hamlet" (la pièce), de "Hamlet" (le personnage)]

Yikes.
 
> So much for the "sauvegarde de la francophonie" - but we have no choice !
> Even with such guidelines, the translation will be a tricky exercise (count
> me in for some help)

Great to hear we can count on you!
 
One of the goals I've had in these specs is both internationalization and
accessibility. Hopefully we can strike some kind of reasonable compromise.
 
> BTW feel like all that has something to do with noodles, knowledge and
> wisdom, but what is this something ?

Noodles are all about wisdom. But if I told you the secret, I'd have to
kill you. Or something like that.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/0/_/337252/_/977271835/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com