From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Tait Subject: "Tag hierarchy" idea Date: Mon, 21 Mar 2011 23:09:21 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015174c1736d0fddd049f063772 Return-path: Received: from [140.186.70.92] (port=53191 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1oE5-0001s1-3H for emacs-orgmode@gnu.org; Mon, 21 Mar 2011 19:09:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1oDz-0003CY-MV for emacs-orgmode@gnu.org; Mon, 21 Mar 2011 19:09:28 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:46500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1oDz-0003CO-Bc for emacs-orgmode@gnu.org; Mon, 21 Mar 2011 19:09:23 -0400 Received: by ewy9 with SMTP id 9so1722596ewy.0 for ; Mon, 21 Mar 2011 16:09:22 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --0015174c1736d0fddd049f063772 Content-Type: text/plain; charset=ISO-8859-1 Hi all This is my first post. First, I'd like to thank all the org-mode developers for a great tool. I'm a technical editor. I am facinated by the pros and cons of structured documents with regard to their ease of use and power. I think that they are probably far too restrictive and cumbersome (looking at you, DITA) for the average technical document. Nevertheless, the idea of modular documents is an appealing one to me. I like conditional text features (e.g. in LyX). In org-mode, I really really love selective export (include/exclude tags) and using #+INCLUDE: for including other files. This gives me enormous flexibility, with zero DITA pain. May I propose an additional feature? I haven't seen anything like it published anywhere, though maybe I am using the incorrect search terms. (I am getting enormous vertigo and time-travel sickness reading up on Lisp, XML, DITA, etc.) It's a pretty basic idea, but I hope you can take a moment to weigh up its potential. We could assign tags to hierarchies of other tags. #+TAG-NEST: (colour(red green blue)) #+TAG-NEST: (type(colour size)) #+TAG-NEST: (car(type price)) or maybe like this. I'd leave it up to someone with actual programming experience and a logical mind (my productive programming was PASCAL in 1991) to suggest a rigorous system that makes sense. #+TAG-NEST: colour > red:green:blue #+TAG-NEST: type > colour:size #+TAG-NEST: car > type:price The point of this would be that selecting, say, "colour" as a tag would bring along "red", "green", and "blue" along with it. The tag "type" would bring "colour", "red", "green", "blue" and "size" with it. The power of this would be that hierarchies could be adjusted and manipulated as necessary. Since there is no one definitive way to tag real world objects and ideas into nice nested boxes (thanks, AI research), we could adjust any tag hierarchies to suit experience and changing priorities. Even hierarchies could just be thrown away without affecting existing tags too much, since tagged headings could just be selected/excluded as usual. This way, we can use concept hierarchies as the disposable conveniences that they are, without getting locked into them. Looking at stuff like XSLT transformation for XML, that'd be worth avoiding. Maybe there is some logical lispy reason why this couldn't work, but I hope this is worthy of your consideration. John ------ While I am here (sorry), I couldn't get #+FILETAGS: to work in org-version 7.4. For example, if I export a file (to html) File1.org with "#+EXPORT_EXCLUDE_TAGS: john", and then I include File2.org, I can see File2.org included as part the export of File1 as expected. If I then set "#+FILETAGS: :john:" in File2, I'd expect File2 to now be excluded, but it still appears. If I then tag a File2 heading as say "* Heading :john:", then it won't appear in the File1 export, as expected. Am I missing something? --0015174c1736d0fddd049f063772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all

This is my first post. First, I'd like to thank all the o= rg-mode developers for a great tool.

I'm a technical editor. I = am facinated by the pros and cons of structured documents with regard to th= eir ease of use and power. I think that they are probably far too restricti= ve and cumbersome (looking at you, DITA) for the average technical document= . Nevertheless, the idea of modular documents is an appealing one to me. I = like conditional text features (e.g. in LyX).

In org-mode, I really really love selective export (include/exclude tag= s) and using #+INCLUDE: for including other files. This gives me enormous f= lexibility, with zero DITA pain.

May I propose an additional featur= e? I haven't seen anything like it published anywhere, though maybe I a= m using the incorrect search terms. (I am getting enormous vertigo and time= -travel sickness reading up on Lisp, XML, DITA, etc.)

It's a pretty basic idea, but I hope you can take a moment to weigh= up its potential.

We could assign tags to hierarchies of other tags= .
=A0

#+TAG-NEST: (colour(red green blue))
#+TAG-NEST: (type(c= olour size))
#+TAG-NEST: (car(type price))

or maybe like this. I'd leave it u= p to someone with actual programming experience and a=20 logical mind (my productive programming was PASCAL in 1991) to suggest a rigorous system that makes sense.

#+TAG-NEST: colour > red:green= :blue
#+TAG-NEST: type > colour:size
#+TAG-NEST: car > type:pr= ice

The point of this would be that selecting, say, "colour&quo= t; as a tag would bring along "red", "green", and "= ;blue" along with it. The tag "type" would bring "colou= r", "red", "green", "blue" and "siz= e" with it.

The power of this would be that hierarchies could be adjusted and manip= ulated as necessary.

Since there is no one definitive way to tag re= al world objects and ideas into nice nested boxes (thanks, AI research), we= could adjust any tag hierarchies to suit experience and changing prioritie= s. Even hierarchies could just be thrown away without affecting existing ta= gs too much, since tagged headings could just be selected/excluded as usual= .

This way, we can use concept hierarchies as the disposable conveniences= that they are, without getting locked into them. Looking at stuff like XSL= T transformation for XML, that'd be worth avoiding.

Maybe there = is some logical lispy reason why this couldn't work, but I hope this is= worthy of your consideration.

John

------

While I am here (sorry), I couldn't get #= +FILETAGS: to work in org-version 7.4.

For example, if I export a fi= le (to html) File1.org=A0 with "#+EXPORT_EXCLUDE_TAGS: john", and= then I include File2.org, I can see File2.org included as part the export = of File1 as expected. If I then set "#+FILETAGS: :john:" in File2= , I'd expect File2 to now be excluded, but it still appears. If I then = tag a File2 heading as say "* Heading :john:", then it won't = appear in the File1 export, as expected. Am I missing something?

--0015174c1736d0fddd049f063772--