Dear Colleagues: During our meeting yesterday the need for a solution to the "broken" definitions process was briefly discussed. I enclose below a relevant e-mail I sent to Dr. Messina (NIST) back in June. Similar information was sent, at about the same time, to all CEDA executives concerned with standards, and to a few key company people concerned with, and knowledgeable of standards. The message reveals also my interest to find a sponsor for the work. My current sponsor for standards activities is Denali, but I stretched already Denali beyond their immediate agenda by unilaterally providing a prototype solution much needed for representing IP-XACT constraints rules. So far the answers were not encouraging. 1. The CEDA requested advice from a few standards concerned organizations, but I have not received any written reply yet:-( 2. Some people in the EDA industry, kindly pointed to the threat of proliferation of "company only standards" as the real issue to be addressed, without realizing that perhaps the structured definition process would disable the current practice - anybody who invents a notation claims a standard. That is because nobody will accept notations which will not be anchored in the definitions, and into clear meaning anymore, and because such notations would be easily reproduced, if information snippets about the definitions would be available therefore the trend could be stopped. I hope this makes some sense. 3. Some other people and/or organizations reacted with the "it is *you* who has to do it as a professional action" reply. While we can start and define a process in the DASC of how to go about the definitions, we should address the issue in the bigger picture, and in any case help clear the anomalies described below (in the attached e-mail). I am still optimistic that we will succeed doing what is proposed below (i.e. create an "EDA Standards Development Manual") Big steps ahead are made these days in the use of (a) institutes (not as that in IEEE, but as a mathematical structure) to harmonise definitions, (b) restricted English to naturally describe domains http://www.jfsowa.com/logic/ace.htm and http://attempto.ifi.unizh.ch/site/ and (c) cathegories for abstracting and structuring types. That way it is expected that formalization in general, the standard creation process will be simplified, but we have to start and try to lean towards the progress. There are many more details I could share here about this definitions, like the perspective of some who thought that a new standard could be completely independent (not anchored into any other standard, or basic definitions), and still be used in conjunction with other standards ?? ;-( Covering also issues like that and other related to the use of advancing XML technology was the purpose of the educational side of my proposal. Please do not take it wrong here. It is my great luck, but also it seems to be a curse, that I see these things 5-6 years ahead of their real "landing" (like pushing "XML in EDA" in 1999). I have been "digging" at these definitions for more than 7 years now (Ron could remember our presentations to the PTAB about introducing inter-operation based on knowledge described in ontologies in the nineties). What that means is just that here there is not an issue of vision anymore, and that we are unfortunately late. Some of you will ask, what changed for people to be ready now? XML technology improved the ability specify structures, the trend to invent notations with non-centralized meanings is unstoppable without shared definitions, and the complexity of standards increased to a level where machine processing of their validation might be necessary. Other reason might be that USPTO has a hard time sorting claims, and that in general advancing into the SoC will require much clearer and shared among standards definitions (when all is done in house you can fix a misunderstanding, but when collaboration occurs you better know what you are talking about). I congratulate you for your patience of reaching here and willing to read the attachment too. I look forward for your comments, Sincerely, Alex Zamfirescu P.S. Had I been busy working on knowledge based standard inter-operation, I might have missed a "recent bumpy transition." My other curse is maybe that the only way I can get your attention is with "insignificant procedural details." :-) The amount of reply to this message will also help me/us clarify this. ---------- Forwarded message ---------- From: Alex Zamfirescu <alex.zamfirescu@gmail.com> Date: Jun 19, 2007 10:57 AM Subject: SDM - EDA Standards Development Manual To: John Messina <jmessina@nist.gov> John: This is something else I wanted to talk to you about. *In am looking * *to finance **my effort to write a modern "EDA Standards Development Manual" * *(SDM).* I did a lot of research in that area and am ready now to get it on an official path. It would be a good resource with simple explanations to "bring people on the same page", get them useful pointers to resources and rational recommendations. What triggered this, is a clear perspective on how standards are developed today in the DASC. Much effort is repeated in defining terms, not all standards which could benefit form the XML technology advances do that, and those groups which take advantage use only 5 or 6 years old technology, and stop at the XML Schema (data) at best, instead of going all the way and define also the knowledge level. Also most of the standards which are descriptive (semantic is not given based on an execution model) do not have a clear anchor in an an information model, so it is hard to enforce them, and most of the time assume that some meaning (and restriction) will be inferred from the name of a tag :-( Most importantly, the groups proceed on these paths because they lack the knowledge of doing better (not that they would not want it). Getting out there with an SDM maybe as a recommended practice would highly benefit all of them. This SDM will not include things like how to reach consensus, or repeat other P&Ps, but it will address what seems to be, the "blind spot" of the people developing EDA standards today. As I explained, one of these blind spots appears to be the progress done in knowledge processing, with three areas needing immediate addressing: 1. Recommended practice for efficient use of XML technology - how to leverage in EDA standards the XML Schema (the only one used today), XML RDF(S), OWL, Description Logic etc., - how to use CLiX, XPATH, XQUARY, and XLINK to improve consistency and ease the development of standards - modern avenues for publishing EDA standards, (PURLs, etc.) 2. Structured definition process - How to create an EDA specific dictionary, and how to enforce its maintenance and re-use Until the IEEE definition process (broken today, see below) will be fixed, the EDA has to solve the problem at least for the EDA domain. The SDM will address this. 3. Unified type system view (at least integer, signed, unsigned, fixed point and floating point expressions should be uniquely understood). A recommended practice in that direction is much overdue. *HOW THE IEEE DEFINITION PROCESS IS BROKEN* Recently I checked to see if we can improve re-use of definitions, design automation abstract definitions, and in general how we are expected to proceed when we generate the new definitions to be included in a standard. Here is what I found: First we read in http://standards.ieee.org/guides/style/section4.html#527 -------------------------------- 10.5 Definitions 10.5.1 General terminology usage English words should be used in accordance with their definitions in the latest edition of *Webster's New Collegiate Dictionary* [B11]. Electrical and electronics terms not defined in *Webster's New Collegiate Dictionary *[B11] should be used in accordance with their definitions in the most recent edition of *The Authoritative Dictionary of IEEE Standards Terms *[B7]. Working groups are strongly encouraged to use definitions that already exist in *The Authoritative Dictionary* [B7] instead of creating new definitions or slightly modifying existing definitions. Working groups shall not incorporate into the definitions clause terms that were already published in *The Authoritative Dictionary* [B7]. However, if the working group feels that including such terms is necessary for effective use of the document, the terms may be placed in an informative annex, entitled *Glossary*. During mandatory ballot coordination of definitions and terms by SCC10, working groups may be asked to validate the use of terms that already exist, or terms that vary slightly from those that already exist in *The Authoritative Dictionary* [B7]. If the definitions in *The Authoritative Dictionary* [B7] do not reflect usage specific to the document, or if terms used are not defined in *The Authoritative Dictionary*[B7], then appropriate definitions shall be provided. Users are also encouraged to use the *IEC Multilingual Dictionary of Electricity, Electronics, and Telecommunications* [B2], and the *IEC International Electrotechnical Vocabulary (IEV) *[B3]. -------------------------------- So far we learned that we have to use [B2], [B3], [B7], and [B11]. Definitions *shall* be provided if they are not given in [B7], or does not reflect those in [B7]. Users are also encouraged to "use" [B2] and [B3], meaning probably that some definition could be found there. Note that this is in possible conflict with the "shall be provided" if not in [B2], but this is another issue. The annex of the guides http://standards.ieee.org /guides/style/annexa.html<http://standards.ieee.org/guides/style/annexa.html> provides clear pointers what is meant [B2] *IEC Multilingual Dictionary of Electricity, Electronics, and Telecommunications*, Amsterdam: Elsevier Science Publishers. [B3] IEC 60050, IEC International Electrotechnical Vocabulary. ... [B7] *IEEE 100, The Authoritative Dictionary of IEEE Standards Terms*, Seventh Edition, New York, Institute of Electrical and Electronics Engineers, Inc. [B11] *Webster's New Collegiate Dictionary.* Springfield, MA: Merriam-Webster, Inc. Then I checked the FAQs about the important [B7] refference http://standards.ieee.org/faqs/Std100.html#Q7 Here are some questions and answers. *What is the IEEE Dictionary?* The IEEE Dictionary, as it is commonly known, is really IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition. IEEE 100 is a product of the IEEE Standards Information Network (SIN). Great!, *How often is the IEEE Dictionary published?* Generally, it has been published at approximately four- to five-year intervals. The current edition of the IEEE Dictionary was published in December 2000. I think the answer sounds funny. However, we know how to deal with work in progress so here is the next question. *Is there any way I can check to see if a more recent term or definition exists than what is shown in the current edition of the IEEE Dictionary?* Currently there is no way to get updated information to what appears in the current edition of IEEE 100. This is no more funny! Don't you think? Before everything is fixed at the IEEE level, we need to deal with this in the EDA. We produce standards, we want them to be quality standards, and we want our life to be simple. Please let me know what you think about the need for an SDM, what group in NIST could help. This could be also a Standards Association concern, an Accellera concern, an IEC TC-93 concern, SI2, or SPIRIT, but the role of NIST is pivotal. It could also be a concern of all EDA companies who need to act together and insure the best known art is used in its standards. I hope that we will not have to start another consortium to find a way to produce the right SDM. I look forward to reading your thoughts. Kind regards, Alex Zamfirescu P.S. Note that the economic side of the recommended practice is two folded. First, new competitive and higher quality tools can be developed and provided if the standards are closer to machine processing, more consistent, and their adoption is accelerated. Second, the efficiency of producing the specifications will increase (and cost will decrease) with fewer hours spent on manual operations, and more time spent on the advancement of the technical merit, matching specific user paradigms, commitment to the right ontology, etc. AZ -- Alex Zamfirescu 650-814-7514 alex.zamfirescu@gmail.com http://alex.zamfirescu.googlepages.com ========= This communication, and its attachments, may contain privileged, or confidential information, intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this communication, and/or shred the materials and any attachments, and are hereby notified that any disclosure, copying or distribution of this communication, or the taking of any action based on it, is strictly prohibited. Interception of e-mail is a crime under the Electronic Communication Privacy Act, 18 U.S.C. 2510-2521 and 2701-2709. If you have received this transmission in error, please notify me by reply e-mail at alex.zamfirescu@gmail.com and destroy the original transmission and its attachments without reading them, or saving them to disk. Thank you for your cooperation in this matter. ========= -- Alex Zamfirescu 650-814-7514 alex.zamfirescu@gmail.com http://alex.zamfirescu.googlepages.com ========= This communication, and its attachments, may contain privileged, or confidential information, intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this communication, and/or shred the materials and any attachments, and are hereby notified that any disclosure, copying or distribution of this communication, or the taking of any action based on it, is strictly prohibited. Interception of e-mail is a crime under the Electronic Communication Privacy Act, 18 U.S.C. 2510-2521 and 2701-2709. If you have received this transmission in error, please notify me by reply e-mail at alex.zamfirescu@gmail.com and destroy the original transmission and its attachments without reading them, or saving them to disk. Thank you for your cooperation in this matter. ========= -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Dec 21 14:54:12 2007
This archive was generated by hypermail 2.1.8 : Fri Dec 21 2007 - 14:54:39 PST