Re: [codelist-comment] Public Review of Context/Value Association using Genericode 1.0

[=?UTF-8?B?4KS14KS/4KS24KWN4KS14KSo4KS+4KSl?= <viswanath7@gmail.com>]

Hello Ken,

Thanks a lot for your quick and elaborate reply for my feedback to the committee. It was my pleasure to have an opportunity to provide feedback on the committee's efforts. Here are the details that were missing in my previous feedback that you required.

In case the feedback requires further explanation, please do not hesitate to indicate me. I shall try to do my best to explain. 

Hope it helps.

Regards,
Viswanath Jayachandran
+31 654375186

On Mon, Dec 7, 2009 at 01:55, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:

At 2009-12-06 23:57 +0100, विशॠवनाथ wrote:

I am writing to provide my feedback for the Context Value Association (CVA) file for generic code 1.0

Thank you, Viswanath, for your comment to the committee.

Reviewing your comment, I feel it needs more substantiation in order for the committee to properly analyze concrete suggestions for changes.  But that won't stop us looking at it.

My first impression on the context-value-association file is, even though the file meets its requirements quite well, the format of the file is complicated, making it hard for users / developers to understand the manner in which it must be authored. In other words, the learning curve is a bit steep.

So noted.  This is a meaningful comment to the committee because it gives us your first impression.  First impressions are important and we can include this comment in our analysis of alternatives.

I believe, If its format can be refactored to something simpler so that the developers can very easily understand the manner in which the file is utilised, the margin of error would be reduced and adopters of it would be significantly high in number.

Makes sense.  But there is a trade-off between perceived complexity, information duplication, information organization, completeness and usability.

The CVA specification is not a tutorial, nor should it be ... it is a specification.  "Refactoring to something simpler" will not meet user needs if the requirements cannot be met in the revised format.  Having something "easily understood" may be addressed by tutorials rather than by changing the specification  itself.

Nevertheless, contributions suggesting simplifications can be measured against the requirements being satisfied by the existing candidate specification.

In an effort to understand the manner in which the CVA must be correctly written, I documented the published draft version and re-wrote the elements of CVA to something more verbose but self-explanatory.  You may find both these xml files attached to this e-mail. Perhaps this helps in your understanding of the idea I am trying to communicate.

Forgive me but I was unable to determine from your "my cva proposal.xml" file how the proposed file satisfies requirements already satisfied by the "current-cva.xml" file.  You have introduced a number of elements that, while they do have verbose names, fail to help me understand the semantics represented.  It is unclear to me how the various elements and attributes are to be used.

I also see ambiguities.  Two attributes with the same name but different meaning are both named rule-set-id= where one of them is the identifier and the other is a reference.  This might be confusing to users.

In order that your suggestion for revision can be suitably weighed by committee  members, I feel it needs to be better documented and better illustrated.  The example you've provided does not illustrate the revised solution to a particular problem set.

The committee members cannot make the time such that each member guess the purpose and application of the proposed elements from a single incomplete example fragment.

I would ask you to please go through the exercise of converting every construct in "current-cva.xml" and illustrate using an instance of your proposed CVA vocabulary how yours satisfies all of the requirements met by the example using the current vocabulary.

Finally, I am unaware whether the feed-back must be provided in a formal manner and the manner in which I am providing a feedback is appropriate. So, please do not hesitate to correct me if I am mistaken in any way.

You have used exactly the correct procedure to submit your comment, thank you.  But in my opinion, not all aspects of the comment are sufficiently documented in a form the committee can work with.

Your comment regarding complexity is duly noted and will be discussed by the committee as part of the disposition of comments received.

I suspect your comment regarding a candidate revision to reduce the complexity is not yet suitable for committee discussion, but we will discuss what you have given us.  The committee is certainly obliged to consider your suggestion in the format it was submitted, but I suggest to you that you provide a more detailed example giving the committee a concrete alternative example to the example provided by the committee.

Thanks a lot in advance for your time and efforts

Thank *you* for your interest in the work of our committee and for taking the time to submit your comment.  With more effort to substantiate your comment, the committee will be better equipped to analyze your suggestions in its review of public comments regarding the proposed vocabulary.

. . . . . . . . . . Ken

--
XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

cva detailed feedback.doc