Feature Driven Development

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

Cheers
Reece

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.

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
well."

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 :)

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:

<feature>
    <name>
        <action>calculate<action>
        the
        <result>total<result>
        of a
        <object>SaleItem<object>
    <name>
<feature>

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?

Paul.

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 :)

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.