Forum OpenACS Q&A: Template Language RFC: deprecating <slave> tag

Collapse
1: Template Language RFC: deprecating <slave> tag
Posted by Carl Coryell-Martin on 07/17/03 09:47 PM
Green Media Toolshed is embarking on our first franchising project and partnering with the CCMC to create the Womens Media Center.

My boss and I were reviewing the technology infrastructure with a WMC representative and we both become slight uncomfortable discussing the <master> and <slave> tags.

One of our internal action items is to replace the <slave> tag with a less loaded word like <child> or something else.  This wasn't the first time that I have felt this discomfort introducing people to templating system.

So, I propose creating a pair of functionally identical tags such as <parent> and <child> and making them interoperable with the old tags and never force people to upgrade their old templates.

I am bringing this issue up because I would like to see this change rolled into the core toolkit so I don't have to think about it again.

I created a ticket to track this issue:

https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=659

I look forward to hearing feedback.  If someone else feels like doing this in their copious free time, great.  If not I will get too it, uh, eventually but probably Q3 2003.

Collapse
2: Re: Template Language RFC: deprecating &lt;slave&gt; tag (response to 1)
Posted by Malte Sussdorff on 07/17/03 11:05 PM
A small notion of encouragement. I understand your issue. But master and slave are commonly used terms in OpenACS with no thoughts behind. So I doubt anyone else will embark on this journey.
Collapse
3: Re: Template Language RFC: deprecating &lt;slave&gt; tag (response to 1)
Posted by Roberto Mello on 07/17/03 11:18 PM
It's also used commonly in IDE drives. I understand the issue but honestly I don't see why one needs to be politically correct there, just for the sake of being PC.

-Roberto

Collapse
4: Re: Template Language RFC: deprecating &lt;slave&gt; tag (response to 1)
Posted by Don Baccus on 07/18/03 12:58 AM
It is also used extensively in the photographic world, for instance one may use photosensors to slave electronic flash units to a single master.

Changing the tags would require every OpenACS 4.x site in the world to change their custom source code when updating, which I imagine would make a fair number of people somewhat unhappy.

Here's a link to an entire engineering genre which makes extensive use of that terminology.

And here's a snippet from a dictionary:

"4. A machine or component controlled by another machine or component."

The other three entries refer to human slavery...

Collapse
5: Re: Template Language RFC: deprecating &lt;slave&gt; tag (response to 1)
Posted by Patrick Giagnocavo on 07/18/03 01:54 AM
I understand your desire to be sensitive.

But a word is not a length of chain with leg irons on it.

Slave is used in many other cases to indicate exactly this kind of realationship.

This reminds me of the recent case where a guy working for the Washington DC used the word "niggardly" in a meeting and was fired for it; the etymology of "niggardly" comes from circa 13th century Middle English and has no relation to "that other N-word."

As a practical matter I don't think slave can be removed.  I wouldn't have a problem with aliasing parent->master and child->slave .

Collapse
6: Re: Template Language RFC: deprecating <slave> tag (response to 1)
Posted by Carl Coryell-Martin on 07/22/03 05:10 PM
Just for the record, I have no intention of making <slave> stop working.  I was just planning on aliasing other less loaded language.

I appreciate that it has a long history as technical terminology, but its much easier for me to just change it than give a discourse about that when I am doing sales or tech support for template authors.

best,

carl

Collapse
7: Re: Template Language RFC: deprecating &lt;slave&gt; tag (response to 1)
Posted by Talli Somekh on 07/22/03 05:16 PM
While at first it seems that Carl's suggestion is perhaps a bit extreme, within the context of his experience it makes sense. Also, considering that he's offering to do the work to make it compatible in both directions is makes things even easier.

Is there any reason if Carl does the work that it couldn't be accepted?

talli