OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

codelist-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]