FDD Interchange (FDDI) Specification 20051027

Jeff De Luca's picture

The main purpose of FDDI is to enable the exchange of FDD project related information between diverse software systems and components.

FDDI (f ĭ dˈē) is pronounced fiddy (as for the word giddy but replacing the g with an f).

fddi20051027.pdf235.25 KB
fddi20051027_xsd.txt13.29 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Vernon's picture

Thanks to the Nebulon team

On behalf of the FDD Tools team, we would like to extend our thanks to the Nebulon team for making this IP available. This looks like a great start.

I've ask the members of the FDD Tools team to review, after which we will provide our comments in a single post. Hopefully this will make the review and comment process easier for everyone.

szego's picture



yes please - the feedback from the dev community is what can make all the difference here! It would be great to hear from not just the people building "shrink wrap" style tools, but others that have their own one-off or in-house solutions that might benefit from a standard interchange format.

I have some example XML fragments that I need to get in order and publish, that should hopefully demonstrate most of the features (no pun intended) of the schema.

I am away on holiday for the next couple of weeks (starting this coming weekend), so unfortunately replies to some of the questions may not get full attention until I return. I'd still encourage everyone to post their questions and findings up here, and get some discussion going before then.

Any and all comments greatly appreciated.

Paul :)

A couple of procedural questions...

First of all - my thanks and congratulations to the Nebulon team for releasing this specification to the community.

Initially I have a couple of procedural questions relating to the maintenance and use of FDDI.

1) Who will control the FDDI spec? Will the maintenance and versioning of FDDI be performed using the open source model or will updates come only from Nebulon?

2) Will there be some way to "certify" a tool as being FDDI compliant? If so who would certify the tool? Or, in your view, would it be up to vendors to "self certify"?

As I become more familiar with the actual spec. I hope to have some more technical questions Eye-wink


Jeff De Luca's picture

Spec Publishing

In answer to your question 1, FDDI will be published by Nebulon. It's an interchange format that requires standardisation. Multiple versions - which is what each of the FDD tools have embedded in them today - does not help.

The FDDI spec is free (as in beer) and via open discussion here it will evolve with Nebulon making the final call. I think that's also free (as in speech) but then I'm not up with the details of such OSS terms or what your definition of them might mean.

The whole of FDD is a complex domain. What model (schema) for interchange that makes sense depends entirely on scope, and with several different tool solutions out there - one tool's scope is not necessarily another's.

Over the next several weeks/months, we'll publish more and more FDDI-related collateral to help move this along.

I look forward to the first demonstration of interchange from one FDD tool to another. I wonder which two tools will be the first? (rhetorical)


Jeff De Luca's picture

FDDI Certification, Branding, etc.

Hi Reece,

re: your question 2. Some sort of FDDI certification/branding is an obvious next step. As is FDD branding (i.e. use of the FDD logo).

I'll write more on this soon.


re: FDDI

I looked at the schema and it looks great. It should allow data interchange between various FDD tools. I have one question about progress reporting. Can the schema handle the situation when the two entities (two aspects, or two projects, or two programs) have different weight?

It is easier to explain with example. Assume I am writing an email server with web-based client. So I have a program “Email Server” with two projects: “Server” and “Web Client”. For argument sake, lets assume that have the same number of features:100. The server is 90% complete, and client is 10% complete. How do we calculate the progress of the program? (0.9 * 100 + 0.1 * 100)/(100 + 100) may not work. It gives 50% completion. However, if web development is more effort-consuming than back-end development, then the 50% will be inaccurate estimation, too high.

Somehow, we have to take into account the “weight” of the projects (and aspects). I saw the only thing in the schema that might address it: “effort” element of the milestone. However, I assume that “effort” describes the percentage within a feature (the 1-40-3-45-10-1 numbers, for example).

I suggest adding optional “weight” attribute to the “progress” element. The default value is “1”, meaning that all the projects within program (aspects within project) will be considered equal, unless specified otherwise. Applying this to the example above, I would assign the weight of 1.5 to the “Web Client” and calculate the progress for the program like this:
(0.9 * 100 * 1 + 0.1 * 100 * 1.5)/(100 * 1 + 100 * 1.5) = 42%

Alternative is to add “featureWeight” attribute to the aspect, so features in one project or aspect are heavier that in another one.

May be you can post a couple of XML examples that would clarify this.

Thanks a lot,

szego's picture

Hi Serguei,a short reply,

Hi Serguei,

a short reply, as I'm on the road. There is no standard way to do this, as comparing different aspects isn't something that I've seen done that way.

The simplest approach - use an extension, either an attribute or element.

If you think this should be something standard, then I'll defer to Jeff on that one. You'll have to convince him.

Regards, Paul.

Jeff De Luca's picture

Use an extension

Hi Sergeui,

you can easily use an extension for this.

Trying to weight aspects together to come up with a single % complete for an entire project is not something I do or recommend. It's yet another way to tightly couple things that don't need to be. I've had no problem whatsoever presenting project status to all levels of management where each aspect is presented separately. It's easy to to talk to differing risks or complexities in one aspect relative to another. And you'll find you want to anyway. You'll have different things to say about one aspect versus another when communicating status.

This should be no surprise as after all, that's why you created the aspect in the first place.

You can choose how many aspects you'd like for a project. An aspect gives you an FBS and associated set of reports for tracking and status. You will create each aspect because that is an aspect of the project for which you want the FDD levels of visibility and communicability. e.g. I want the FDD visibility and communicability for the UI, the PD, the SI and the System Testing and so I create four aspects.

When communicating status you'll often (almost always) want to talk about that aspect of a project versus another when communicating status (for example preseting the UI aspect reports and then discuss UI issues before moving on to the PD aspect).

Rolling the aspects together into a single overall % complete figure doesn't really give us much as you need to walk through each of the aspects anyway (and it tightly couples things that don't need be).

I agree it's seductive to want to do this. I know because I've tried it myself. In practice it has never added anything for me (for the reasons described above) plus it is extremely difficult to try and weight one aspect relative to another.


Re: Use an extension

Jeff, Paul,
You two convinced me :-) I looked at schema once again and noticed that “progress” element is optional, which means that we do not have to report completion percent if we are not sure how to calculate it. Extensions may handle it.


Jeff De Luca's picture

Can you explain some more?

Hi Serguei,

I'm not sure I follow your reply. I didn't see the progress element as related to your question?

Can you explain again what you are trying to do?


The extension element

My only comments are around the extension element.

Instead of requiring all the elements to live in a special container element, why not allow for element extension in the same way that attribute extension is done? Allow extension elements to be placed anywhere within the document providing they are in a different namespace.

So for example

<project name="FYR" xmlns:koz="http://projects.koziarski.net/fddi-extensions"> 
  <koz:link rel="homepage" href="http://projects.koziarski.net/fyr/" />
  <koz:link rel="scm" href="http://koziarski.net/svn/repos/fyr/" />

szego's picture

Consistent Extensions

Hi Koz,

a very good question. My first reaction: yeah, why don't we do that? I cannot see any downside, and it certainly makes things more consistent.

The initial extension element idea was lifted from XMI - but that doesn't mean it's any good. They might have other reasons why they need that degree of "identifiability" - does anyone in the tools community want to comment on that? What's it used for?

As for complexity I can't see that it changes much. Now we have an arbitrary element anywhere, as opposed to in specific places with a pre-defined form. You still have the issue of how to reliably represent this information internally and reproduce it.

I will try a variation of the schema that works how you suggest and see it it goes - most likely this weekend. Stay tuned...

Paul :)

Vernon's picture

Comments on FDDI schema

After review and consideration, the FDD Tools team has the following comments/questions regarding the FDDI schema.

1) <aspect>, <program> and <project> can all appear directly below <fddi>. I'm wondering about the consideration of not formalizing the structure to require <project><program><aspect></aspect></program></project> as the structure. It seems to me that requiring this structure simplifies the processing in a lightweight (no XML parser) environment, which may be desirable in some cases.

2) Programs <program> can be nested (<program><program></program></program>. Is there a practical reason for this?

3) What are the considerations regarding the optional count, completion, and status attributes of the <progress> element? Shouldn't these be calculated/inferred from the sub-elements? (I can understand it may be convenient to do this, but if a tool actually wanted to implement this as a shortcut or convenience the <extension> element could be used. To maximize interoperatibilty, optional elements should not be assumed, but providing them for 'convenience' within the Schema may result in assumptions. (If I liken this to database design, 'normal' form discourages the inclusion of fields which can be calculated from other relationships.)

4) The FDDI specification document notes "An individual feature has a percentage completion figure, derived from its milestones, and an overall status. For each level of aggregation above this we record the rolled up percentage completion and the total number of features." Since the percentage completion feature is derived from it's milestones, doesn't it make sense that the milestones would be sub-elements of progress? That is, the milestones would be rolled up to determine both status (nonstarted, underway, completed, etc) and count (at the <feature> level)?

5) Regarding milestones, does it make sense to define these in more detail, such as the activities defined in the Coloring Book? These lay a foundation for % completion, so leaving this loosely defined may reduce the clarity of reporting project process across tools. (Not that you can't define additional milestones, but in general terms I think an advantage of FDD is the breakdown and definition of effort associated with different phases. I think this should be reflected in the Schema design.)

6) One specific item, the <name> below <feature> seems to be a bit inconsistent with the rest of the Schema design. At other levels (<project>, <aspect> and <subject>), name is an attribute, but in <feature> it is a sub-element, and the actual name would become a text node of the sub-element. Any reason for this? If not I recommend it be an attribute of <feature> just as it is the super-elements. (From an object-oriented inheritance perspective, this is much cleaner as well, as these <project>, <aspect>, <subject> and <feature> share many common elements and attributes. (Frankly speaking, we have adopted a standard of using Elements, and specifically the text-node within Elements to represent actual data, with attributes defining meta-data. For example we would prefer <Date><Month>10</Month><Day>12</Day><Year>1995</Year></Date> to <date month='10' day='12' year='1995'/>, but the FDDI seems to have a preference for the use of attributes -- nothing wrong with that, just a bit of difference in philosophy. Given the philosophy, making name an attribute of the <feature> element seems to be more consistent.

7) To further extend the date example above, I think the planned and actual attributes in the Milestone element should be broken down further to specify plannedMonth, plannedDay, plannedYear, actualMonth, actualDay, and actualYear. We have experienced problems with our own implementation in terms of date processing across various Locales, and were initially planning moving towards a structure similar to what I outlined in item 6 above, but now see the FDDI Schema as an opportunity to correct this deficiency. (Hopefully helping others to avoid a design problem we encountered.)

8) We understand the desire to keep the FDDI Schema as simple as possible, but I think it would be to everyone's advantage to also define a standard for high-level resource definition as well, at least at a level of being able to associate the initials attribute of the <activity> and <feature> elements with individuals. This shouldn't add a great deal of complexity, but would provide a great deal of value in terms of reporting (features owned by individual, activity status by individual, etc.).

Hopefully these comments are valuable to the community at large, and will spawn some additional discussion around the specification. We're looking forward to working with everyone to get a 'draft standard' finalized and implemented in some tools.

Best regards, and warm holiday greetings,

admin's picture

Careful using less than

I corrected your comment so that all your tags were not swallowed by Drupal and I deleted the duplicate comment. The trick is to escape the opening angle bracket by using


instead of


Edit: We've added a basic filter to make this much easier. Simply wrap everything inside of <code></code> tags that you don't want treated as actual html/xml/php. Not all input formats have this, check on your submission form which input formats do this code filtering for you.

szego's picture

Well Considered

Hi Vernon,

firstly a huge thanks for the detailed feedback - it's great. I will try to address all of the points, but might split it over a few posts to try and make it easier to manage (or at least for me to get my head around).

Regarding the first couple of points: programs, projects and aspects. The doco is rather terse here, all it says on programs is:

"We also want to allow the aggregation of projects in some way. Program management is
typically how this is done, so we provide a simple hierarchical organisation of project as

So in answer to (2), the reason for a program being able to contain another program is to achieve the hierarchical structure mentioned above. What the meaning of any level in such a hierachy might be is beyond the scope of the specification. Jeff is a good person to ask about some examples of program management structures here.

Regarding question (1), you raise an interesting point. With flexibility comes complexity, but I'm not sure that it's warranted in this case. The reason behin this choice was the knowledge that some people only ever want to deal with information at the Aspect level, and think of this single set of data as "the project". Forcing them to add in the extra Program and Project elements seemed a waste.

However, the flip side of this is of course the added complexity of having to deal with one of 3 elements at the "root" of our tree.

So if we force the structure, what's the downside? All I can see is that people who don't use the extra levels put in dummy ones. No problem - their tool can easily add them in. What they do when they receive a file that really does have several non-dummy Programs and/or Projects is up to them to define. I think I like that better - it really is their problem, and not everyone else's.

So unless anyone can think of a reason why I shouldn't, I'm proposing to adopt the alternative in question (1) by defining a fixed structure.

Paul :)

Jeff De Luca's picture

One structure

Regarding question (1), you raise an interesting point. With flexibility comes complexity, but I'm not sure that it's warranted in this case. The reason behin this choice was the knowledge that some people only ever want to deal with information at the Aspect level, and think of this single set of data as "the project". Forcing them to add in the extra Program and Project elements seemed a waste.

However, the flip side of this is of course the added complexity of having to deal with one of 3 elements at the "root" of our tree.

So if we force the structure, what's the downside? All I can see is that people who don't use the extra levels put in dummy ones. No problem - their tool can easily add them in. What they do when they receive a file that really does have several non-dummy Programs and/or Projects is up to them to define. I think I like that better - it really is their problem, and not everyone else's.

So unless anyone can think of a reason why I shouldn't, I'm proposing to adopt the alternative in question (1) by defining a fixed structure.

Yep. Fix the structure. The only overhead is that most people will be forced to carry a dummy program. Below program it doesn't really make sense to not have project and it's not worth the parsing complexity of "it could be program or project or aspect at the root" to cater fot this.

Vernon's picture

One Structure

Cool! Check one off the list :-)

szego's picture

Draft Standard

A comment of Vernon's just reminded me of something:

"We're looking forward to working with everyone to get a 'draft standard' finalized and implemented in some tools."

I would just like to re-iterate to everyone that I view this very much as still being a *draft* standard. As a work in progress, it may change in the near future. When it gets further review we will attempt to finalise a version that hopefully everyone can work to.

Regards, Paul.

szego's picture

Name attributes

Hi Vernon,

regarding question (6) - Yes, it's inconsistent. There is an age old debate in XML circles about the use of attributes or elements for character data.

Strictly speaking, we should ALWAYS use an element. To deal with things like attributed strings properly there's really no other way. What many people do, including myself in this case, is get lazy and just use attributes 'cos they are easier. That is until you can't cope with real-life situations like internationalisation and multi-lanaguage support.

So.... busted! I'd better go back and see what things should really be elements.... at first glance this includes all naming attributes, subject prefix, activity and feature initials (not withstanding your other point on this later).

Back to the question: why is feature name a sub element? It has to do with a naming standard we use often, which we call the "feature naming template". It breaks down a feature name into this form:

[action] the [result] by|for|of|to a(n) [object]

You've probably seen it discussed elsewhere. I went back and forwards on whether to make this naming structure explicit in the schema, and eventually decided against it. At one point the feature name allowed a mixed content model, allowing things like this:

        of a

This all got too complex very quickly. The options I ended up with were:
(a) make the structure explicit, as above
(b) make it an element, and allow mixed content
(c) make it an xsd:string element
(d) make it an attribute like everything else

The problem with (a) is allowing it to work both ways - not everyone wants this, it's very specific and doesn't apply in all the situations where FDD would, and especially not all the situations where just this reporting style is useful. Allowing you to either specify it this way or not has the same issues you raised in question (1) about complexity. It gets very complex very quickly, and I felt it was not reasonable in this case.

Knowing that we shouldn't really put character data in an element rules out (d).

So now I'm left with (b) or (c) again. The most useful is actually (b), but it's harder to implement full lossless round-trip import/export with that case. It's not hard to import - you just get the character data and ignore everything else. Note that this really applies to all of the character attributes.

What do you think? Comment please, anyone?


Vernon's picture

Name Attributes

Hi Paul,

Thanks for sharing the considerations around this decision. I understand and agree (remember my preference for <elements> over attributes for data anyway), but it seems to me this same logic should then be applied to the <subject> and <activity> etc. levels as well, as these also have associated templates.

As you might have noted, in the FDD Tools project we provide the 'suggested' naming conventions in the text box associated with the various node levels, but we don't enforce these in any way, we just provide them as a reference and then store the node as a string.

I can envision the possibility that a more complete and prescriptive syntax here (again, applied across the various node levels) could be used by a tool to auto-generate code or similar artifacts, but, as with other areas where we're discussing complexity, I would consider this to be an extreme case and beyond the scope of project management (and therefore more suitable as an extension instead of as part of the standard schema).

So, my vote is for xsd:string, with <name> applied to other levels as well.


szego's picture


Hi Vernon,

this kind of follows on from the discussion of the feature name element in question (6), and that's the dates you mention later on in (6) and also in (7).

The solution I used was to adopt a standard date format: xsd:date. It uses ISO8601 as the basis for representing date values (which can have timezones specified in them). Due to this I didn't break down the date any further.

So an example would be: 2002-10-10, or if you wanted to specify a timezone: 2002-10-10+13:00 might do the trick.

I can't see the point of making this an element, in the same way as other character data. It's not character "data" really, we're just using a textual representation of numeric data, so I can't see the point of any finer grained control over this thing.

The other place we have a date is the target attribute, which only uses the xsd:gYearMonth datatype. An example would be 2005-12 for December 2005.

Let me know if that helps at all - any issues please let me know.

Thanks, Paul :)

Vernon's picture


Hi Paul,

I'd argue the point of the date not being data, since it's part of the project (as opposed to meta-data, which might be the date/time that an element was inserted into the project by the respective tool), but I do like the idea of using a standardized time representation, and I think your proposal of using the ISO8601 standard is quite suitable. We should just make sure this is reflected in the documentation, so everyone follows the same standard. In terms of markup, then, perhaps even something like <date format="ISO8601"><planned>2002-10-10</planned><actual>2002-10-10></actual></date>.


szego's picture


Hi Vernon,

In answer to question (3), I think the underlying issue here is one of scope. The scope at present is where we arbitrarily drew the line - we needed a starting point. We think we're close, but it's certainly open for discussion. What we settled on was:

The scope in this draft is to allow you to communicate enough information to produce
the “standard” reports that are mentioned in the FDD documentation

So this includes

  • Plan view
  • Weekly Summary
  • Parking Lot

If you think about the parking lot, we only need to communicate the Subject Areas and Business Activities, and their rolled up progress. We don't need the breakdown of kpi's, or the individual milestones. So the optional aspects to the progress element are simply to reflect the various ways in which it can be used.

So I think the schema reflects the current scope reasonably well, but like I said: it's open for discussion. What do you think?

Thanks, Paul :)

p.s. the other issue regarding derived data is interesting, but I think answering the scope questions set the stage for resolving the approach there.

Jeff De Luca's picture

Scope Indeed

yep - where to set the scope really is the big question. Given where we have set it for now, then the derived data is sort-of ok. With a scope of the reports only, then there are interesting possibilites for standardised or generic reporting engines that are really just simple transforms (because of the derived data).

If you set the scope to a transactional view, then all sorts of things come in - not just the people resources but also workpackages and so on. And, of course, the need for processing now beyond what simple transforms can do.

The scope wasn't to be for any tool to dump ALL of its data into a standardised schema. I don't believe such a standardised schema is even possible as there are many different possible FDD tool solutions, with very different scopes, that make perfect sense. In fact, there are even more generic tool solutions and scopes that make sense.

That all said, a discussion of the right scope for FDDI or even if there should be two levels is something we are happy to have.

Vernon's picture


Hi Paul,

I think we're on the same page regarding scope. Perhaps I'm wearing my FDD Tools goggles too much here, but as our 'parking lot' is implemented, it's actually drill down, with each display node being a roll-up of the sub-nodes (except for the <feature> level, which reflects the status of the milestones -- which for our purposes have adopted the 6 items identified in the Coloring Book and their associated completion percentage values). Calculating the items eliminates the need to update attributes when elements are changed. To be more specific, my thoughts when I looked at this are "I can't imagine us writing those attributes, since it's information gathered from sub-nodes and is optional. And, do I really want to trust what someone inserts into the attribute, or do I just want to parse and calculate as I would for my own model?"

I guess from another perspective it's possible to insert these attributes directly, with no supporting sub-model, but to me this would be dirty. Where's the information to back what's being represented by the super-node? What if the information represented in the super-node and the sub-nodes don't match?

Stated another way, it's FEATURE driven development, not activity, subject, aspect, or project driven development. I believe the features (and the associated milestones) should drive the model from the bottom up, instead of top-down or somewhere in the middle.

Again, perhaps I'm too close to the subject relative to FDD Tools and how we've implemented this, but I think allowing the model to support super-nodes which don't have sub-node levels validating the information represented is a bit dubious.

Just my thoughts. I'm quite interested in insight others might have regarding this topic.


szego's picture

Milestone Definitions

Hi Vernon,

regarding point (5), you mention defining the milestones in more detail. I'm not 100% sure what you mean by this - you can define your own set of custom milestones at the Aspect level, and their percentage completion. You can have whatever milestones you want, so for example you can have one set for PD, and another set for the UI (which is very common for us). The "aspectDesc" and "milestoneDesc" complex types define these in the schema.

If you feel there's something more that needs to go into defining these, please let me know.

What is perhaps not clear is the semantics when you don't define any milestones. Perhaps it would be useful to nominate a "standard" set of milestones (e.g. the 6 from the book) that will be applied in the absence of any explicit values? Let me know what you think.

Regards, Paul :)

Jeff De Luca's picture

Milestones aren't optional per aspect

What is perhaps not clear is the semantics when you don't define any milestones. Perhaps it would be useful to nominate a "standard" set of milestones (e.g. the 6 from the book) that will be applied in the absence of any explicit values? Let me know what you think.

This implies milestones are optional for an aspect - I don't think they should be optional. (they can't be).

Vernon's picture

Milestones per aspect

Hi Jeff,

I'm not sure I follow here. Do you mean that milestones must be defined at the <aspect> level, or that they must be defined somewhere within the tree at the <aspect> level or below it? (i.e. they could be defined at the <feature> level and rolled-up into the <aspect> level?


Jeff De Luca's picture

Milestones are defined per Aspect

Read this thread and then this one please for an understanding of what an Aspect is.

This model fragment is what I'm talking about.

An FDD Feature

The collection of blue MilestoneDescriptions hangs off Aspect.

The disconnect here could be the blues vs the pinks in that model.

Vernon's picture


Hi Paul,

My thoughts here were specifically related to the 6 milestones identified in the Coloring Book. I believe one of the benefits of FDD is that it actually provides specific milestones and prescribed percentages these milestones should assume relative to a unit of work. (I'm not familiar with another methodology which as taken such bold initiative to not 'waffle' on what milestones should be used and how they should be weighed -- kudos to the FDD designers for leading the way.) I'm of the opinion that these should be included at the feature level.

As to other milestones and their percentages, I'm a bit less clear about how these apply, particularly given the prescriptive percentages (which add up to 100% per feature) for these milestones. Perhaps you, Jeff, or someone else can shed some additional light on my ignorance around this point, and what the best way to model alternatives might be.


Jeff De Luca's picture


The percentages are NOT prescriptive. The numbers for a PD feature are a "suggested starting set." The whole point of this (with my project manager hat on) is accuracy. You plug in the numbers for your team team at this time on this piece of work (project). And the percentage numbers will vary from one Aspect to the next (of course). And from team to team and project to project.

What do you do if you don't know what your numbers are? You measure for the first few weeks. The granularity of features gives you completed features every week.

Now, the milestones themselves were chosen very deliberately and very carefully and that comes from my 20+ years experience.

Jeff De Luca's picture

Start New Topics

This topic (thread) will soon get impossible to read. Let's close out the current questions in this topic, but please everyone - start a new topic for each new issue or related set of questions you have re: FDDI.