Item task_id not being used in taskjuggler export

Item task_id not being used in taskjuggler export

[John Hendy]

I seem to be having trouble getting custom task_id values used for my
taskjuggler file. From ox-taskjuggler.el:

#+begin_quote
(defun org-taskjuggler--build-task (task info)
  "Return a task declaration.

TASK is a headline.  INFO is a plist used as a communication
channel.

All valid attributes from TASK are inserted.  If TASK defines
a property \"task_id\" it will be used as the id for this task.
Otherwise it will use the ID property.  If neither is defined
a unique id will be associated to it."

[snip]

#+end_quote

However, my headlines are still using the Org-assigned values for this...

#+begin_org

* Project :taskjuggler_project:
  SCHEDULED: <2013-03-01 Fri>
** Technical  :T:
   :PROPERTIES:
   :task_id:  T
   :END:
*** Sub task
    :PROPERTIES:
    :task_id:  T1
    :END:

#+end_org

This gets exported as:

#+begin_tjp

task technical "Technical" {
  purge allocate
  allocate jwhendy
  task sub "Sub task" {
    milestone
  }
}

#+end_tjp

Variations:
- I also tried using =:task_id: "T"= to see if it needed to be in quotes
- Tried changing my drawer name to TASK_ID to check for case-sensitivity

The results of both were the same. Is this something on my end or a
but in ox-taskjuggler.el?


Thanks,
John

Re: Item task_id not being used in taskjuggler export

[John Hendy]

On Sun, Mar 31, 2013 at 7:04 PM, John Hendy <jw.hendy@gmail.com> wrote:
> I seem to be having trouble getting custom task_id values used for my
> taskjuggler file. From ox-taskjuggler.el:
>
> #+begin_quote
> (defun org-taskjuggler--build-task (task info)
>   "Return a task declaration.
>
> TASK is a headline.  INFO is a plist used as a communication
> channel.
>
> All valid attributes from TASK are inserted.  If TASK defines
> a property \"task_id\" it will be used as the id for this task.
> Otherwise it will use the ID property.  If neither is defined
> a unique id will be associated to it."
>
> [snip]
>
> #+end_quote
>
> However, my headlines are still using the Org-assigned values for this...
>
> #+begin_org
>
> * Project :taskjuggler_project:
>   SCHEDULED: <2013-03-01 Fri>
> ** Technical  :T:
>    :PROPERTIES:
>    :task_id:  T
>    :END:
> *** Sub task
>     :PROPERTIES:
>     :task_id:  T1
>     :END:
>
> #+end_org
>
> This gets exported as:
>
> #+begin_tjp
>
> task technical "Technical" {
>   purge allocate
>   allocate jwhendy
>   task sub "Sub task" {
>     milestone
>   }
> }
>
> #+end_tjp
>
> Variations:
> - I also tried using =:task_id: "T"= to see if it needed to be in quotes
> - Tried changing my drawer name to TASK_ID to check for case-sensitivity
>
> The results of both were the same. Is this something on my end or a
> but in ox-taskjuggler.el?
>
>
> Thanks,
> John


As a followup, within a section, the :depends: attribute is being
correctly resolved, even though naming is incorrect. I've taken to
giving each area a single letter task_id, such as:

#+begin_org
* Project
** Technical
   :PROPERTIES:
   :TASK_ID:  T
   :END:
*** Sub task
    :PROPERTIES:
    :task_id:  T1
    :END:
*** Sub task2
*** Sub task
    :PROPERTIES:
    :task_id:  T2
    :depends: T1
    :END:

#+end_org

That's resolving deps correctly, but not naming correctly:

#+begin_tjp

  task sub "Sub task" {
    milestone
  }
  task sub_task2 "Sub task2" {
    depends !sub
    milestone

#+end_tjp

The problem with this is when depending on something outside of that
particular subtask; the TJ syntax is to use =!= as the equivalent to a
period with respect to directories. So to refer to a task in another
bucket, you need to do something like =:depends: !!M.M1= to refer to
the Milestone bucket (task_id = M), subtask M1 task.

This isn't working with Org taskjuggler export. Not being able to name
task is a huge inconvenience, as one has to use Org's unique-id naming
function, which I'd prefer not to do. It's easier (at least for me) to
just unfold all the property drawers and refer to things by their two
character id. I also tagged each top headline with it's letter bucket
":T:" so that I can just count the item order in the list for it's
resulting subtask id (e.g. "T2").


Best regards,
John

Re: Item task_id not being used in taskjuggler export

[John Hendy]

On Sun, Mar 31, 2013 at 7:16 PM, John Hendy <jw.hendy@gmail.com> wrote:
> On Sun, Mar 31, 2013 at 7:04 PM, John Hendy <jw.hendy@gmail.com> wrote:
>> I seem to be having trouble getting custom task_id values used for my
>> taskjuggler file. From ox-taskjuggler.el:
>>
>> #+begin_quote
>> (defun org-taskjuggler--build-task (task info)
>>   "Return a task declaration.
>>
>> TASK is a headline.  INFO is a plist used as a communication
>> channel.
>>
>> All valid attributes from TASK are inserted.  If TASK defines
>> a property \"task_id\" it will be used as the id for this task.
>> Otherwise it will use the ID property.  If neither is defined
>> a unique id will be associated to it."
>>
>> [snip]
>>
>> #+end_quote
>>
>> However, my headlines are still using the Org-assigned values for this...
>>
>> #+begin_org
>>
>> * Project :taskjuggler_project:
>>   SCHEDULED: <2013-03-01 Fri>
>> ** Technical  :T:
>>    :PROPERTIES:
>>    :task_id:  T
>>    :END:
>> *** Sub task
>>     :PROPERTIES:
>>     :task_id:  T1
>>     :END:
>>
>> #+end_org
>>
>> This gets exported as:
>>
>> #+begin_tjp
>>
>> task technical "Technical" {
>>   purge allocate
>>   allocate jwhendy
>>   task sub "Sub task" {
>>     milestone
>>   }
>> }
>>
>> #+end_tjp
>>
>> Variations:
>> - I also tried using =:task_id: "T"= to see if it needed to be in quotes
>> - Tried changing my drawer name to TASK_ID to check for case-sensitivity
>>
>> The results of both were the same. Is this something on my end or a
>> but in ox-taskjuggler.el?
>>
>>
>> Thanks,
>> John
>
>
> As a followup, within a section, the :depends: attribute is being
> correctly resolved, even though naming is incorrect. I've taken to
> giving each area a single letter task_id, such as:
>
> #+begin_org
> * Project
> ** Technical
>    :PROPERTIES:
>    :TASK_ID:  T
>    :END:
> *** Sub task
>     :PROPERTIES:
>     :task_id:  T1
>     :END:
> *** Sub task2
> *** Sub task
>     :PROPERTIES:
>     :task_id:  T2
>     :depends: T1
>     :END:
>
> #+end_org
>
> That's resolving deps correctly, but not naming correctly:
>
> #+begin_tjp
>
>   task sub "Sub task" {
>     milestone
>   }
>   task sub_task2 "Sub task2" {
>     depends !sub
>     milestone
>
> #+end_tjp
>
> The problem with this is when depending on something outside of that
> particular subtask; the TJ syntax is to use =!= as the equivalent to a
> period with respect to directories. So to refer to a task in another
> bucket, you need to do something like =:depends: !!M.M1= to refer to
> the Milestone bucket (task_id = M), subtask M1 task.
>
> This isn't working with Org taskjuggler export. Not being able to name
> task is a huge inconvenience, as one has to use Org's unique-id naming
> function, which I'd prefer not to do. It's easier (at least for me) to
> just unfold all the property drawers and refer to things by their two
> character id. I also tagged each top headline with it's letter bucket
> ":T:" so that I can just count the item order in the list for it's
> resulting subtask id (e.g. "T2").
>
>
> Best regards,
> John

Last addendum. I think this is what's going on:
- ox-taskjuggler will use task_id var for dependencies, but not the
actual task_id
- thus, it's resolving my dependencies (within a sub-task bucket), but
not using the actual names

Here's how unique-ids are assigned:

#+begin_src ox-taskjuggler.el

(defun org-taskjuggler-assign-task-ids (tasks info)
  "Assign a unique ID to each task in TASKS.
TASKS is a list of headlines.  Return value is an alist between
headlines and their associated ID.  IDs are hierarchical, which
means they only need to be unique among the task siblings."
  (let* (alist
         (build-id
          (lambda (tasks local-ids)
            (org-element-map tasks 'headline
              (lambda (task)
                (let ((id (org-taskjuggler--build-unique-id task local-ids)))
                  (push id local-ids)
                  (push (cons task id) alist)
                  (funcall build-id (org-element-contents task) nil)))
              info nil 'headline))))
    (funcall build-id tasks nil)
    alist))

#+end_src

Nothing related to task_id. That's calling this, which just makes sure
the initially parsed list is actually unique, and does some syntax
tweaking to make sure things work for what taskjuggler expects for
task_id syntax:

#+begin_src ox-taskjuggler.el

(defun org-taskjuggler--build-unique-id (item unique-ids)
  "Return a unique id for a given task or a resource.
ITEM is an `headline' type element representing the task or
resource.  Its id is derived from its name and made unique
against UNIQUE-IDS.  If the (downcased) first token of the
headline is not unique try to add more (downcased) tokens of the
headline or finally add more underscore characters (\"_\")."
  (let* ((parts (org-split-string (org-element-property :raw-value item)))
(id (org-taskjuggler--clean-id (downcase (pop parts)))))
    ;; Try to add more parts of the headline to make it unique.
    (while (and (car parts) (member id unique-ids))
      (setq id (concat id "_"
                       (org-taskjuggler--clean-id (downcase (pop parts))))))
    ;; If it's still not unique, add "_".
    (while (member id unique-ids)
      (setq id (concat id "_")))
    id))

#+end_src

But later on, the function =(defun
org-taskjuggler-resolve-dependencies (task info)= will use task_id
property values to resolve deps!?

My suggestion (similar to the :start: property definition for a top
project headline before) would be to use task_id as the actual ID
/unless/ one isn't provided. Then assign the unique variable
definition for Orgmode. Better behavior would involve just passing the
depends value straight through to the .tjp file and letting
TaskJuggler resolve it.

So far, I find most errors on TJ compilation anyway, not via Org... so
that seems fine for now. Down the road, I'd love to see compilation of
the .tjp included in this, and errors could be made known the same way
LaTeX compilation errors appear.


John

Re: Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

Hello,

John Hendy <jw.hendy@gmail.com> writes:

> I seem to be having trouble getting custom task_id values used for my
> taskjuggler file.

Thank you for the detailed report. Would the attached patch fix the
problem?


Regards,

-- 
Nicolas Goaziou

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-taskjuggler-Use-task_id-property-when-specified.patch --]
[-- Type: text/x-patch, Size: 2142 bytes --]

From 30b8328292fc09b3f1ae84b469d1c574c19bfa58 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Mon, 1 Apr 2013 16:08:37 +0200
Subject: [PATCH] ox-taskjuggler: Use task_id property when specified

* contrib/lisp/ox-taskjuggler.el (org-taskjuggler--build-unique-id):
  Use specified id (TASK_ID property) when possible.
---
 contrib/lisp/ox-taskjuggler.el | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index cdc9195..5b2e5cc 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -411,16 +411,19 @@ resource.  Its id is derived from its name and made unique
 against UNIQUE-IDS.  If the (downcased) first token of the
 headline is not unique try to add more (downcased) tokens of the
 headline or finally add more underscore characters (\"_\")."
-  (let* ((parts (org-split-string (org-element-property :raw-value item)))
-	 (id (org-taskjuggler--clean-id (downcase (pop parts)))))
-    ;; Try to add more parts of the headline to make it unique.
-    (while (and (car parts) (member id unique-ids))
-      (setq id (concat id "_"
-                       (org-taskjuggler--clean-id (downcase (pop parts))))))
-    ;; If it's still not unique, add "_".
-    (while (member id unique-ids)
-      (setq id (concat id "_")))
-    id))
+  (let ((id (org-string-nw-p (org-element-property :TASK_ID item))))
+    ;; If an id is specified, use it, as long as it's unique.
+    (if (not (member id unique-ids)) id
+      (let* ((parts (org-split-string (org-element-property :raw-value item)))
+	     (id (org-taskjuggler--clean-id (downcase (pop parts)))))
+	;; Try to add more parts of the headline to make it unique.
+	(while (and (car parts) (member id unique-ids))
+	  (setq id (concat id "_"
+			   (org-taskjuggler--clean-id (downcase (pop parts))))))
+	;; If it's still not unique, add "_".
+	(while (member id unique-ids)
+	  (setq id (concat id "_")))
+	id))))
 
 (defun org-taskjuggler--clean-id (id)
   "Clean and return ID to make it acceptable for TaskJuggler.
-- 
1.8.2

Re: Item task_id not being used in taskjuggler export

[John Hendy]

On Mon, Apr 1, 2013 at 9:21 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> John Hendy <jw.hendy@gmail.com> writes:
>
>> I seem to be having trouble getting custom task_id values used for my
>> taskjuggler file.
>
> Thank you for the detailed report. Would the attached patch fix the
> problem?
>

Thanks for the quick response! It fixes the naming issue. My tasks now
indeed keep the task_id that I assign.

I still have the issue of depending on a task not in the current
subtree, but perhaps I'm just not using the exporter correctly:

#+begin_src org
* Project  :taskjuggler_project:

** Milestones  :M:
*** Task
    :PROPERTIES:
    :task_id:       M2
    :depends:  ??? what goes here to depend on T.T8 ???
    :END:

** Technical  :T:
   :PROPERTIES:
   :task_id:  T
   :END:
*** Task
    :PROPERTIES:
    :task_id:  T8
    :depends:  T6 T7
    :duration: 1d
    :END:

#+end_src

The TJ syntax would be !!T.T8 to depend on T8 from "outside" of the
Technical bucket. At present, the exporter isn't picking this up and
there's no depends attribute with the exported headline (tried T8,
T.T8, and !!T.T8).



Thanks,
John

>
> Regards,
>
> --
> Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

John Hendy <jw.hendy@gmail.com> writes:

> I still have the issue of depending on a task not in the current
> subtree, but perhaps I'm just not using the exporter correctly:

There was indeed a bug in the dependencies formatting. It should now be
fixed in master. Could you confirm it?

> *** Task
>     :PROPERTIES:
>     :task_id:       M2
>     :depends:  ??? what goes here to depend on T.T8 ???

It should be :depends: T8

Thank you for the feedback.


Regards,

-- 
Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export

[John Hendy]

On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> I still have the issue of depending on a task not in the current
>> subtree, but perhaps I'm just not using the exporter correctly:
>
> There was indeed a bug in the dependencies formatting. It should now be
> fixed in master. Could you confirm it?
>
>> *** Task
>>     :PROPERTIES:
>>     :task_id:       M2
>>     :depends:  ??? what goes here to depend on T.T8 ???
>
> It should be :depends: T8
>
> Thank you for the feedback.
>

That *would* work, but ox-taskjuggler has to correct for the fact that
T8 does not live in M2's bucket (M). Using T8 gives me this:

#+begin_src TJ
  task M2 "Task" {
    depends !T8
    milestone
  }
#+end_src

But that gives a compilation error becaust tj3 is looking for task
M.T8 when it should be T.T8.

#+begin_src terminal

$ tj3 test.tjp

Reading file test.tjp                                        [      Done      ]
test.tjp:11: Error in scenario plan: Task M.M2 has unknown depends M.T8%===   ]

#+end_src

Perhaps this analogy would help. I've just created two directories and
two files. Here's the output of =tree= at the command line:

|-- M
|   |-- M1
|   `-- M2
|-- T
|   |-- T1
|   `-- T2

I want to link M1 to T1. The current behavior is trying to do so with
./T1, which doesn't work since M/T1 doesn't exist. I have to do
../T/T1.

This is how TJ works, which is why it can't resolve T8 by itself,
unless you correct for the proper relative path with respect to the
current parent. Relative directory path periods are akin to TJ's =!=
syntax.

- ./file -> !task_id
- ../file -> !!task_id
- ../dir/file -> !!task_id (dir).task_id (file)


Best regards,
John

>
> Regards,
>
> --
> Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

John Hendy <jw.hendy@gmail.com> writes:

> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> I still have the issue of depending on a task not in the current
>>> subtree, but perhaps I'm just not using the exporter correctly:
>>
>> There was indeed a bug in the dependencies formatting. It should now be
>> fixed in master. Could you confirm it?
>>
>>> *** Task
>>>     :PROPERTIES:
>>>     :task_id:       M2
>>>     :depends:  ??? what goes here to depend on T.T8 ???
>>
>> It should be :depends: T8
>>
>> Thank you for the feedback.
>>
>
> That *would* work, but ox-taskjuggler has to correct for the fact that
> T8 does not live in M2's bucket (M). Using T8 gives me this:
>
>
> #+begin_src TJ
>   task M2 "Task" {
>     depends !T8
>     milestone
>   }
> #+end_src

I cannot reproduce it. With:

* Project  :taskjuggler_project:

  ** Milestones  :M:
  *** Task
      :PROPERTIES:
      :task_id: M2
      :depends: T8
      :END:

  ** Technical  :T:
     :PROPERTIES:
     :task_id:  T
     :END:
  *** Task
      :PROPERTIES:
      :task_id:  T8
      :duration: 1d
      :END:

I get:

  task project "Project" {
    purge allocate
    allocate nicolas
    task milestones "Milestones" {
      task M2 "Task" {
        depends !!T.T8
        milestone
      }
    }
    task T "Technical" {
      task T8 "Task" {
        duration 1d
      }
    }
  }

which looks correct. Did you reload Org properly after update?


Regards,

-- 
Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export

[John Hendy]

On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>> John Hendy <jw.hendy@gmail.com> writes:
>>>
>>>> I still have the issue of depending on a task not in the current
>>>> subtree, but perhaps I'm just not using the exporter correctly:
>>>
>>> There was indeed a bug in the dependencies formatting. It should now be
>>> fixed in master. Could you confirm it?
>>>
>>>> *** Task
>>>>     :PROPERTIES:
>>>>     :task_id:       M2
>>>>     :depends:  ??? what goes here to depend on T.T8 ???
>>>
>>> It should be :depends: T8
>>>
>>> Thank you for the feedback.
>>>
>>
>> That *would* work, but ox-taskjuggler has to correct for the fact that
>> T8 does not live in M2's bucket (M). Using T8 gives me this:
>>
>>
>> #+begin_src TJ
>>   task M2 "Task" {
>>     depends !T8
>>     milestone
>>   }
>> #+end_src
>
> I cannot reproduce it. With:
>
> * Project  :taskjuggler_project:
>
>   ** Milestones  :M:
>   *** Task
>       :PROPERTIES:
>       :task_id: M2
>       :depends: T8
>       :END:
>
>   ** Technical  :T:
>      :PROPERTIES:
>      :task_id:  T
>      :END:
>   *** Task
>       :PROPERTIES:
>       :task_id:  T8
>       :duration: 1d
>       :END:
>
> I get:
>
>   task project "Project" {
>     purge allocate
>     allocate nicolas
>     task milestones "Milestones" {
>       task M2 "Task" {
>         depends !!T.T8
>         milestone
>       }
>     }
>     task T "Technical" {
>       task T8 "Task" {
>         duration 1d
>       }
>     }
>   }
>
> which looks correct. Did you reload Org properly after update?

Process:
- Save your patch to ~/Downloads/patch.patch
- cd ~/.elisp/org.git
- git branch tj-test
- git checkout tj-test
- patch -p1 < ~/Downloads/patch.patch
- make clean && make
- start fresh Emacs session

What perplexes me is that the id's mostly work (showing that the patch
definitely changed from the master branch behavior), but not the same
as you. With no task_id for Milestones, I'm getting:

task nil "Milestones" {

and you're getting

task milestones "Milestones" {

I'm also not getting the resolving of non-sibling depends attributes
(getting just !T8 instead of !!T.T8).

Did I not apply the patch or rebuild org properly? I'm pretty bad with
git, and it surprises me that `git status` shows that ox-taskjuggler
is modified when I switch back to master. I would have expected that
my master branch would be oblivious to the changes I made on the
tj-test branch (with `git branch tj-test && git checkout tj-test`).


Thanks,
John

>
>
> Regards,
>
> --
> Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

John Hendy <jw.hendy@gmail.com> writes:

> Process:
> - Save your patch to ~/Downloads/patch.patch
> - cd ~/.elisp/org.git
> - git branch tj-test
> - git checkout tj-test
> - patch -p1 < ~/Downloads/patch.patch
> - make clean && make
> - start fresh Emacs session

Dismiss the patch. I pushed the changes into master. You should update
Org, reload it, and try again.


Regards,

-- 
Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export

[John Hendy]

On Mon, Apr 1, 2013 at 12:05 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> Process:
>> - Save your patch to ~/Downloads/patch.patch
>> - cd ~/.elisp/org.git
>> - git branch tj-test
>> - git checkout tj-test
>> - patch -p1 < ~/Downloads/patch.patch
>> - make clean && make
>> - start fresh Emacs session
>
> Dismiss the patch. I pushed the changes into master. You should update
> Org, reload it, and try again.

Sorry -- I thought you were still describing the behavior of the patch
you sent. Posted in the other thread with the results, which are that:
- ID is correctly assigned now
- Depends resolve as long as there is only one global instance of that
specific task_id
- If you depend on a non-globally-unique task_id (e.g. there is an
M.T1 and also a T.T1, and you use =:depends: T1=), that task will end
up depending on both of them.


Best regards,
John

>
>
> Regards,
>
> --
> Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Buddy Butterfly]

Hi,

regarding your example

  ** Milestones  :M:
  *** Task
      :PROPERTIES:
      :task_id: M2
      :depends: T8
      :END:

  ** Technical  :T:
     :PROPERTIES:
     :task_id:  T
     :END:
  *** Task
      :PROPERTIES:
      :task_id:  T8
      :duration: 1d
      :END:


I would like to discus what I mean with a prefix.
At the moment oex tries to mirror some functionality of
tj to org mode. From an architectural point of view I
would do this only for few selected functionalities.
Otherwise you developers have to always adapt code to
tj. If you would implement generic tj properties that
will be exported as is, then one could easily write
the tj stuff itself.

The problem becomes obvious with your example above.
Herr you expect that T8 would be unique across all
tasks. If there are some other task paths with a task of
T8 then this will not work. You will always run after
tj implementing what they have implemented. Why not
write:

  :depends: !!T.T8

directly? This is what should be done. Leave the tj
logic to tj and do not try to map it to org-mode.
The more you map the more difficult to maintain, etc.

Also, you will likely only implement subsets of tj
properties.

For example, there are properties missing like

  :workinghours:

Lets look at an example. Suppose
we would prefix all taskjuggler properties with "tj_"
and org-mode would export tj_ properties as is.
People then would directly code the dependency
themself.

Your example would look like
(if directly replaced)

  ** Milestones  :M:
  *** Task
      :PROPERTIES:
      :tj_task_id: M2
      :tj_depends: !!T.T8
      :END:

  ** Technical  :T:
     :PROPERTIES:
     :tj_task_id:  T
     :END:
  *** Task
      :PROPERTIES:
      :tj_task_id:  T8
      :tj_duration: 1d
      :END:

Also, properties to the project tag should go into the
project task. With the functionality above, it would be easy to:

* Project  :taskjuggler_project:
  :workinhours: mon - fri 08:00 - 17:00

Or give a flag:


  ** Technical  :T:
     :PROPERTIES:
     :tj_task_id:  T
     :END:
  *** Task
      :PROPERTIES:
      :tj_task_id:  T8
      :tj_duration: 1d
      :tj_flag: tech8flag
      :END:


I have some other points to discuss. Will create a separate thread for it.

Cheers,
Matt



Am 01.04.2013 18:57, schrieb John Hendy:
> On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>>> John Hendy <jw.hendy@gmail.com> writes:
>>>>
>>>>> I still have the issue of depending on a task not in the current
>>>>> subtree, but perhaps I'm just not using the exporter correctly:
>>>> There was indeed a bug in the dependencies formatting. It should now be
>>>> fixed in master. Could you confirm it?
>>>>
>>>>> *** Task
>>>>>     :PROPERTIES:
>>>>>     :task_id:       M2
>>>>>     :depends:  ??? what goes here to depend on T.T8 ???
>>>> It should be :depends: T8
>>>>
>>>> Thank you for the feedback.
>>>>
>>> That *would* work, but ox-taskjuggler has to correct for the fact that
>>> T8 does not live in M2's bucket (M). Using T8 gives me this:
>>>
>>>
>>> #+begin_src TJ
>>>   task M2 "Task" {
>>>     depends !T8
>>>     milestone
>>>   }
>>> #+end_src
>> I cannot reproduce it. With:
>>
>> * Project  :taskjuggler_project:
>>
>>   ** Milestones  :M:
>>   *** Task
>>       :PROPERTIES:
>>       :task_id: M2
>>       :depends: T8
>>       :END:
>>
>>   ** Technical  :T:
>>      :PROPERTIES:
>>      :task_id:  T
>>      :END:
>>   *** Task
>>       :PROPERTIES:
>>       :task_id:  T8
>>       :duration: 1d
>>       :END:
>>
>> I get:
>>
>>   task project "Project" {
>>     purge allocate
>>     allocate nicolas
>>     task milestones "Milestones" {
>>       task M2 "Task" {
>>         depends !!T.T8
>>         milestone
>>       }
>>     }
>>     task T "Technical" {
>>       task T8 "Task" {
>>         duration 1d
>>       }
>>     }
>>   }
>>
>> which looks correct. Did you reload Org properly after update?
> Process:
> - Save your patch to ~/Downloads/patch.patch
> - cd ~/.elisp/org.git
> - git branch tj-test
> - git checkout tj-test
> - patch -p1 < ~/Downloads/patch.patch
> - make clean && make
> - start fresh Emacs session
>
> What perplexes me is that the id's mostly work (showing that the patch
> definitely changed from the master branch behavior), but not the same
> as you. With no task_id for Milestones, I'm getting:
>
> task nil "Milestones" {
>
> and you're getting
>
> task milestones "Milestones" {
>
> I'm also not getting the resolving of non-sibling depends attributes
> (getting just !T8 instead of !!T.T8).
>
> Did I not apply the patch or rebuild org properly? I'm pretty bad with
> git, and it surprises me that `git status` shows that ox-taskjuggler
> is modified when I switch back to master. I would have expected that
> my master branch would be oblivious to the changes I made on the
> tj-test branch (with `git branch tj-test && git checkout tj-test`).
>
>
> Thanks,
> John
>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Buddy Butterfly]

Correction, see below...

Am 01.04.2013 22:56, schrieb Buddy Butterfly:
> Hi,
>
> regarding your example
>
>   ** Milestones  :M:
>   *** Task
>       :PROPERTIES:
>       :task_id: M2
>       :depends: T8
>       :END:
>
>   ** Technical  :T:
>      :PROPERTIES:
>      :task_id:  T
>      :END:
>   *** Task
>       :PROPERTIES:
>       :task_id:  T8
>       :duration: 1d
>       :END:
>
>
> I would like to discus what I mean with a prefix.
> At the moment oex tries to mirror some functionality of
> tj to org mode. From an architectural point of view I
> would do this only for few selected functionalities.
> Otherwise you developers have to always adapt code to
> tj. If you would implement generic tj properties that
> will be exported as is, then one could easily write
> the tj stuff itself.
>
> The problem becomes obvious with your example above.
> Herr you expect that T8 would be unique across all
> tasks. If there are some other task paths with a task of
> T8 then this will not work. You will always run after
> tj implementing what they have implemented. Why not
> write:
>
>   :depends: !!T.T8
>
> directly? This is what should be done. Leave the tj
> logic to tj and do not try to map it to org-mode.
> The more you map the more difficult to maintain, etc.
>
> Also, you will likely only implement subsets of tj
> properties.
>
> For example, there are properties missing like
>
>   :workinghours:
>
> Lets look at an example. Suppose
> we would prefix all taskjuggler properties with "tj_"
> and org-mode would export tj_ properties as is.
> People then would directly code the dependency
> themself.
>
> Your example would look like
> (if directly replaced)
>
>   ** Milestones  :M:
>   *** Task
>       :PROPERTIES:
>       :tj_task_id: M2
>       :tj_depends: !!T.T8
>       :END:
>
>   ** Technical  :T:
>      :PROPERTIES:
>      :tj_task_id:  T
>      :END:
>   *** Task
>       :PROPERTIES:
>       :tj_task_id:  T8
>       :tj_duration: 1d
>       :END:
>
> Also, properties to the project tag should go into the
> project task. With the functionality above, it would be easy to:
>
> * Project  :taskjuggler_project:
>   :tj_workinhours: mon - fri 08:00 - 17:00
>
> Or give a flag:
>
>
>   ** Technical  :T:
>      :PROPERTIES:
>      :tj_task_id:  T
>      :END:
>   *** Task
>       :PROPERTIES:
>       :tj_task_id:  T8
>       :tj_duration: 1d
>       :tj_flag: tech8flag
>       :END:
>
>
> I have some other points to discuss. Will create a separate thread for it.
>
> Cheers,
> Matt
>
>
>
> Am 01.04.2013 18:57, schrieb John Hendy:
>> On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>> John Hendy <jw.hendy@gmail.com> writes:
>>>
>>>> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>>>> John Hendy <jw.hendy@gmail.com> writes:
>>>>>
>>>>>> I still have the issue of depending on a task not in the current
>>>>>> subtree, but perhaps I'm just not using the exporter correctly:
>>>>> There was indeed a bug in the dependencies formatting. It should now be
>>>>> fixed in master. Could you confirm it?
>>>>>
>>>>>> *** Task
>>>>>>     :PROPERTIES:
>>>>>>     :task_id:       M2
>>>>>>     :depends:  ??? what goes here to depend on T.T8 ???
>>>>> It should be :depends: T8
>>>>>
>>>>> Thank you for the feedback.
>>>>>
>>>> That *would* work, but ox-taskjuggler has to correct for the fact that
>>>> T8 does not live in M2's bucket (M). Using T8 gives me this:
>>>>
>>>>
>>>> #+begin_src TJ
>>>>   task M2 "Task" {
>>>>     depends !T8
>>>>     milestone
>>>>   }
>>>> #+end_src
>>> I cannot reproduce it. With:
>>>
>>> * Project  :taskjuggler_project:
>>>
>>>   ** Milestones  :M:
>>>   *** Task
>>>       :PROPERTIES:
>>>       :task_id: M2
>>>       :depends: T8
>>>       :END:
>>>
>>>   ** Technical  :T:
>>>      :PROPERTIES:
>>>      :task_id:  T
>>>      :END:
>>>   *** Task
>>>       :PROPERTIES:
>>>       :task_id:  T8
>>>       :duration: 1d
>>>       :END:
>>>
>>> I get:
>>>
>>>   task project "Project" {
>>>     purge allocate
>>>     allocate nicolas
>>>     task milestones "Milestones" {
>>>       task M2 "Task" {
>>>         depends !!T.T8
>>>         milestone
>>>       }
>>>     }
>>>     task T "Technical" {
>>>       task T8 "Task" {
>>>         duration 1d
>>>       }
>>>     }
>>>   }
>>>
>>> which looks correct. Did you reload Org properly after update?
>> Process:
>> - Save your patch to ~/Downloads/patch.patch
>> - cd ~/.elisp/org.git
>> - git branch tj-test
>> - git checkout tj-test
>> - patch -p1 < ~/Downloads/patch.patch
>> - make clean && make
>> - start fresh Emacs session
>>
>> What perplexes me is that the id's mostly work (showing that the patch
>> definitely changed from the master branch behavior), but not the same
>> as you. With no task_id for Milestones, I'm getting:
>>
>> task nil "Milestones" {
>>
>> and you're getting
>>
>> task milestones "Milestones" {
>>
>> I'm also not getting the resolving of non-sibling depends attributes
>> (getting just !T8 instead of !!T.T8).
>>
>> Did I not apply the patch or rebuild org properly? I'm pretty bad with
>> git, and it surprises me that `git status` shows that ox-taskjuggler
>> is modified when I switch back to master. I would have expected that
>> my master branch would be oblivious to the changes I made on the
>> tj-test branch (with `git branch tj-test && git checkout tj-test`).
>>
>>
>> Thanks,
>> John
>>
>>> Regards,
>>>
>>> --
>>> Nicolas Goaziou
>

Re: Item task_id not being used in taskjuggler export & tj prefixing

[John Hendy]

On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly <buddy.butterfly@web.de> wrote:
>
> Hi,
>
> regarding your example
>
>   ** Milestones  :M:
>   *** Task
>       :PROPERTIES:
>       :task_id: M2
>       :depends: T8
>       :END:
>
>   ** Technical  :T:
>      :PROPERTIES:
>      :task_id:  T
>      :END:
>   *** Task
>       :PROPERTIES:
>       :task_id:  T8
>       :duration: 1d
>       :END:
>
>
> I would like to discus what I mean with a prefix.
> At the moment oex tries to mirror some functionality of
> tj to org mode. From an architectural point of view I
> would do this only for few selected functionalities.
> Otherwise you developers have to always adapt code to
> tj. If you would implement generic tj properties that
> will be exported as is, then one could easily write
> the tj stuff itself.
>
> The problem becomes obvious with your example above.
> Herr you expect that T8 would be unique across all
> tasks. If there are some other task paths with a task of
> T8 then this will not work. You will always run after
> tj implementing what they have implemented. Why not
> write:
>
>   :depends: !!T.T8
>
> directly? This is what should be done. Leave the tj
> logic to tj and do not try to map it to org-mode.
> The more you map the more difficult to maintain, etc.
>

I agree and would prefer this. Especially since folks wanting to
export and being allowed to access tj functionality through drawers
are probably going to anticipate using actual tj syntax in those
drawers. Since tj only forces unique global ids (one can have M.T8,
T.T8, etc.), this would solve the issue of ambiguity should one decide
to use non-globally unique task ids. In fact, many projects may very
well use a lot of repetitive tasks with the same properties.

In mine, I have some tasks regarding shipping products to various
countries. This way I could just have a bunch of country-specific
headlines like:

* Country
** Ship product

* Country 2
** Ship product

And could give all the ** Ship... tasks the same id since their
Country parent would make it globally unique.

For now, I'm just happy to have functionality restored so I can use
Org and not hand-edit the files after exporting :) I have a potential
IRC date with Christian Egli sometime this week... perhaps you should
join and add your feedback? One of my other points of input would be
that something like C-c l (Org store link at point) would be great.
Unique ids could be inserted as depends with some simple key strokes
and I would't have to use numbered IDs at all. They'd stay with the
tasks no matter where I moved them.

For that... I'd actually prefer *not* to have to explicitly name the
parent since they could move wherever I put them with no consequence.


John

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Nicolas Goaziou]

John Hendy <jw.hendy@gmail.com> writes:

> I agree and would prefer this. Especially since folks wanting to
> export and being allowed to access tj functionality through drawers
> are probably going to anticipate using actual tj syntax in those
> drawers. Since tj only forces unique global ids (one can have M.T8,
> T.T8, etc.), this would solve the issue of ambiguity should one decide
> to use non-globally unique task ids. In fact, many projects may very
> well use a lot of repetitive tasks with the same properties.
>
> In mine, I have some tasks regarding shipping products to various
> countries. This way I could just have a bunch of country-specific
> headlines like:
>
> * Country
> ** Ship product
>
> * Country 2
> ** Ship product
>
> And could give all the ** Ship... tasks the same id since their
> Country parent would make it globally unique.

You can already do so. IDs only have to be unique within the task
siblings.

> For now, I'm just happy to have functionality restored so I can use
> Org and not hand-edit the files after exporting :) I have a potential
> IRC date with Christian Egli sometime this week... perhaps you should
> join and add your feedback? One of my other points of input would be
> that something like C-c l (Org store link at point) would be great.
> Unique ids could be inserted as depends with some simple key strokes
> and I would't have to use numbered IDs at all. They'd stay with the
> tasks no matter where I moved them.
>
> For that... I'd actually prefer *not* to have to explicitly name the
> parent since they could move wherever I put them with no consequence.

You don't have to name parents either. You only need to name tasks that
will be used as a dependency.


Regards,

-- 
Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export & tj prefixing

[John Hendy]

On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> I agree and would prefer this. Especially since folks wanting to
>> export and being allowed to access tj functionality through drawers
>> are probably going to anticipate using actual tj syntax in those
>> drawers. Since tj only forces unique global ids (one can have M.T8,
>> T.T8, etc.), this would solve the issue of ambiguity should one decide
>> to use non-globally unique task ids. In fact, many projects may very
>> well use a lot of repetitive tasks with the same properties.
>>
>> In mine, I have some tasks regarding shipping products to various
>> countries. This way I could just have a bunch of country-specific
>> headlines like:
>>
>> * Country
>> ** Ship product
>>
>> * Country 2
>> ** Ship product
>>
>> And could give all the ** Ship... tasks the same id since their
>> Country parent would make it globally unique.
>
> You can already do so. IDs only have to be unique within the task
> siblings.

True, one can name tasks identically as long as they have no identical
siblings... but the point was the since one can only specify the
lowest level of id (e.g. "T1" instead of "T.T1"), Org doesn't know how
to resolve them properly. Consider this  modified test file:

#+begin_src org

* Project  :taskjuggler_project:

** Milestones  :M:
*** M.M1
      :PROPERTIES:
      :task_id: M1
      :depends: T1
      :END:
*** M.T1
    :PROPERTIES:
    :task_id:  T1
    :END:
** Technical  :T:
     :PROPERTIES:
     :task_id:  T
     :END:
*** T.T1
       :PROPERTIES:
       :task_id:  T1
       :END:

#+end_src

The resultant TJ export:

#+begin_src tj

task milestones "Milestones" {
  purge allocate
  allocate jwhendy
  task M1 "M.M1" {
    depends !T1, !!T.T1
    milestone
  }
  task T1 "M.T1" {
    milestone
  }
}
task T "Technical" {
  task T1 "T.T1" {
    milestone
  }
}

#+end_src

Task M1 ends up depending on both M.T1 (represented as !T1) /and/
T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
no way to set a depends option to target the specific T1 they wanted.
Setting =:depends: !!T.T1= ignores the :depends: property entirely.


Best regards,
John

>
>> For now, I'm just happy to have functionality restored so I can use
>> Org and not hand-edit the files after exporting :) I have a potential
>> IRC date with Christian Egli sometime this week... perhaps you should
>> join and add your feedback? One of my other points of input would be
>> that something like C-c l (Org store link at point) would be great.
>> Unique ids could be inserted as depends with some simple key strokes
>> and I would't have to use numbered IDs at all. They'd stay with the
>> tasks no matter where I moved them.
>>
>> For that... I'd actually prefer *not* to have to explicitly name the
>> parent since they could move wherever I put them with no consequence.
>
> You don't have to name parents either. You only need to name tasks that
> will be used as a dependency.
>

True, which is nice. But we're torn between:
- Letting Org name the parent whatever it wants, but then having to
figure out the org-generated parent id so we can do =:depends:
parent.subtask=, or

- Specifically naming the parent to have control over the task_id, but
having to change it because we move it later (and then updating all
=:depends: parent.task_id= properties accordingly)

And in either case, there's still no way to depend on a specific
=parent.task_id= combination.


Best regards,
John

>
> Regards,
>
> --
> Nicolas Goaziou

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Christian Egli]

John Hendy <jw.hendy@gmail.com> writes:

> On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

>> You can already do so. IDs only have to be unique within the task
>> siblings.
>
> True, one can name tasks identically as long as they have no identical
> siblings... but the point was the since one can only specify the
> lowest level of id (e.g. "T1" instead of "T.T1"), Org doesn't know how
> to resolve them properly. 

AFAIK task_ids have to be globally unique if you want to use them for
dependencies.

> Task M1 ends up depending on both M.T1 (represented as !T1) /and/
> T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
> no way to set a depends option to target the specific T1 they wanted.
> Setting =:depends: !!T.T1= ignores the :depends: property entirely.

The TaskJuggler exporter gives you 3 ways to express a dependency:

1. using ORDERED on the parent task
2. using "previous-sibling"
3. using a task_id of another task. This has to be a unique id,
   otherwise you end up depending all the other tasks that have this
   task_id.

>> You don't have to name parents either. You only need to name tasks that
>> will be used as a dependency.
>
> True, which is nice. But we're torn between:
> - Letting Org name the parent whatever it wants, but then having to
> figure out the org-generated parent id so we can do =:depends:
> parent.subtask=, or
>
> - Specifically naming the parent to have control over the task_id, but
> having to change it because we move it later (and then updating all
> =:depends: parent.task_id= properties accordingly)
>
> And in either case, there's still no way to depend on a specific
> =parent.task_id= combination.

I don't understand this. Why do you need to name parents (or assign them
a task_id)? As Nicolas says: all you have to do is to give the task you
want to depend on a task_id. 

As an aside I thought you could also use plain ID to express
dependencies. But from looking at the code this doesn't seem supported.
I think the reason why yet another id (namely task_id) is used, is that
this allows for short human readable ids where as the standard ID is
generally generated by org mode and is cryptic and much longer.

HTH
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Buddy Butterfly]

Hi John,

regarding your "potential" IRC date with Christian Egli, I would like
to join, if I*ll find the time. For when is it scheduled? I have also posted
a base for discussion here on the list.

Thanks and best regards,
Matt



Am 01.04.2013 23:53, schrieb John Hendy:
> On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly <buddy.butterfly@web.de> wrote:
>> Hi,
>>
>> regarding your example
>>
>>   ** Milestones  :M:
>>   *** Task
>>       :PROPERTIES:
>>       :task_id: M2
>>       :depends: T8
>>       :END:
>>
>>   ** Technical  :T:
>>      :PROPERTIES:
>>      :task_id:  T
>>      :END:
>>   *** Task
>>       :PROPERTIES:
>>       :task_id:  T8
>>       :duration: 1d
>>       :END:
>>
>>
>> I would like to discus what I mean with a prefix.
>> At the moment oex tries to mirror some functionality of
>> tj to org mode. From an architectural point of view I
>> would do this only for few selected functionalities.
>> Otherwise you developers have to always adapt code to
>> tj. If you would implement generic tj properties that
>> will be exported as is, then one could easily write
>> the tj stuff itself.
>>
>> The problem becomes obvious with your example above.
>> Herr you expect that T8 would be unique across all
>> tasks. If there are some other task paths with a task of
>> T8 then this will not work. You will always run after
>> tj implementing what they have implemented. Why not
>> write:
>>
>>   :depends: !!T.T8
>>
>> directly? This is what should be done. Leave the tj
>> logic to tj and do not try to map it to org-mode.
>> The more you map the more difficult to maintain, etc.
>>
> I agree and would prefer this. Especially since folks wanting to
> export and being allowed to access tj functionality through drawers
> are probably going to anticipate using actual tj syntax in those
> drawers. Since tj only forces unique global ids (one can have M.T8,
> T.T8, etc.), this would solve the issue of ambiguity should one decide
> to use non-globally unique task ids. In fact, many projects may very
> well use a lot of repetitive tasks with the same properties.
>
> In mine, I have some tasks regarding shipping products to various
> countries. This way I could just have a bunch of country-specific
> headlines like:
>
> * Country
> ** Ship product
>
> * Country 2
> ** Ship product
>
> And could give all the ** Ship... tasks the same id since their
> Country parent would make it globally unique.
>
> For now, I'm just happy to have functionality restored so I can use
> Org and not hand-edit the files after exporting :) I have a potential
> IRC date with Christian Egli sometime this week... perhaps you should
> join and add your feedback? One of my other points of input would be
> that something like C-c l (Org store link at point) would be great.
> Unique ids could be inserted as depends with some simple key strokes
> and I would't have to use numbered IDs at all. They'd stay with the
> tasks no matter where I moved them.
>
> For that... I'd actually prefer *not* to have to explicitly name the
> parent since they could move wherever I put them with no consequence.
>
>
> John

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Christian Egli]

John Hendy <jw.hendy@gmail.com> writes:

> Unique ids could be inserted as depends with some simple key strokes
> and I would't have to use numbered IDs at all. They'd stay with the
> tasks no matter where I moved them.
>
> For that... I'd actually prefer *not* to have to explicitly name the
> parent since they could move wherever I put them with no consequence.

`org-id-copy' will insert a unique ID into your entry (ie your task) and
at the same time store it in your kill ring, so you can then yank it
where you have the dependency. Can you try this with a custom key
binding? As far as I know the dependency resolution should also work
with unique id (aka ID) not just with task_ids.

HTH
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: Item task_id not being used in taskjuggler export & tj prefixing

[Christian Egli]

Buddy Butterfly <buddy.butterfly@web.de> writes:


> The problem becomes obvious with your example above.
> Herr you expect that T8 would be unique across all
> tasks. If there are some other task paths with a task of
> T8 then this will not work. 

True, task_ids have to be unique across tasks. For me this was never a
problem as I usually do not have that many dependencies (and hence need
only a few task_ids) and org-mode has built in infrastructure to create
unique ids.

> You will always run after
> tj implementing what they have implemented. Why not
> write:
>
>   :depends: !!T.T8
>
> directly? 

Because IMHO org-mode has more to offer in terms of dependencies. I
think that the ORDERED and the BLOCKER stuff gives you a good way to
model dependencies that is expressive and covers a lot of use cases
nicely. TaskJuggler dependencies is fairly low level I think. I'd like
to express my dependencies at a higher level. 

Hope that helps
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland