Issue 8962: Spec too complex? (xtce-rtf) Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov) Nature: Uncategorized Issue Severity: Summary: Too complex, ( I have some examples from the ASIST meeting ). Resolution: Revised Text: Actions taken: August 5, 2005: received issue Discussion: End of Annotations:===== m: "Kevin Rice" To: Cc: "Jonathan gal-edd" , "Jane K. Marquart" Subject: issues from NASA GSFC JWST Mission Date: Fri, 5 Aug 2005 14:04:59 -0400 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-OriginalArrivalTime: 05 Aug 2005 18:05:00.0495 (UTC) FILETIME=[3247B5F0:01C599E8] 4. Too complex, ( I have some examples from the ASIST meeting ). Date: Tue, 16 Aug 2005 10:23:00 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en To: Juergen Boldt Cc: issues@omg.org, xtce-rtf@omg.org Subject: Re: issues 8959 - 8962 -- XTCE RTF issues Juergen Boldt wrote: Issues From: "Kevin Rice" This is issue # 8959 Propose that XTCE ( at this point ) will be limited to exchange data I am not sure what this means. To exchange data meaninfully there must be a full model of the meaning and structure of the data. So XTCE attempts to be that model. Of course, modeling the data is different from modeling the software. XTCE does not try to model how actions are to be done. Do we need to explicit say this in the documentation? It would be best if there were an explicit list of what is not to be in XTCE so that the spaceDTF can begin work on stadardizing them. Propose that XTCE ( at this point ) will be limited to exchange and not to all mission data Well, it needs to cover all data that goes up and down and all data that determines when this happens and all data that is needed for calibration. If there is other data then that is probably out of scope (for now). An example or two of other stuff would be helpful. ================================================================= This is issue # 8960 too much leeway how to use the standard Ambiguity - The is too much leeway how to use the standard, and things are left for interpretation. The standard allows / calls for users to add thier own items when they are missing. Need to tighten the standard so things will be done consistently Yes. This is the place to discuss specific ambiguities and we can vote on proper usage at the meetings and either put in more XML facets to control things or add rules in the documentation. We probably should have a section in the documentation on proper usage that is not explicit in the schema. ==================================================================== This is issue # 8961 USE CCSDS examples how to use the standard USE CCSDS examples how to use the standard ( we can provide data set with tlm & commnad) ======================================================================== This is issue # 8962 Spec too complex? Too complex, ( I have some examples from the ASIST meeting ). Are we going to discuss this at the Atlanta meeting? This is not exactly a valid RTF issue as written. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Date: Mon, 12 Sep 2005 12:36:04 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en To: Juergen Boldt Cc: xtce-rtf@omg.org Subject: Re: Fwd: Re: issues 8959 - 8962 -- XTCE RTF issues This is issue # 8962 Spec too complex? There is a single guiding principle that the XML/database world has agreed upon as The Way. It was the point of departure between SGML, the predecesor of XML, and XML, although it was already clear to the database gurus for some time. The overaching rule is "separate display requirements from pure information." That is, one is to allow the "database schema" (broadly interpreted) to be totally independent of the manner or purpose of data presentation AND of data collection. By this principle one allows for the greatest freedom in reuseability of information even into unforseen uses. In practice what does this mean? It means that schema should be designed to hold the facts and just the facts without concern for specific usage nor data collection procedure or purpose. It should be technically correct and complete and that is all. There should be an effort for it to contain no holes where information could exist but has no place to go. If such info is discovered, XML provides for easy extension to immediately provide additional containers. But, what about complexity and the shear enormous size of the resulting schema? How is anyone to fill out or find what they want in such weighty schema? The answer to that is ALWAYS by transformation in the display. Typically, one creates multiple stylesheets to fill-in forms or Word Templates etc. for various user types to fill in the info. So one could have XXXLite/Med/Full forms for different data collectors to use depending on their needs. Likewise, for different views on the data, one would have XXXLite/Med/Full display pages. Several browser have pull down menus to select the stylesheet or one can provide the choice in the displayed page itself. But creating multiple schemas for the same topic may lead to disastrous results. There will inevitably be some group that wants something between lite and medium who may create the medium-lite schema, etc. Extensions may be added to one of non-full versions but not to the full version and so they become unsynchronized. Worst of all, extensions to Lite or Med may be added to hold a few items that are in Full, but do so in a way inconsistent with Full. It just is not necessary nor wise. Our instincts to create a full robost technically correct schema was right on. Where it can be logically modularized by topic, it should be. Schemas inheriting it should accept the whole thing or whole modules. Then, it is just fine to implement only certain parts of it, as needed, by creating simple forms and/or display stylesheets for just the elements reasonable for the specific application or use. We might have arranged it such that a Med is simply composed of includes/inheritance of a Lite, and a Full inherits from Med and then extends that, and then I would say that this may not be too harmful since it is logically still a single schema. But, the above problems can still arise and is simply modularizing along an axis that is unnecessary. Ed Date: Mon, 12 Sep 2005 13:26:09 -0400 (EDT) Subject: Re: Fwd: Re: issues 8959 - 8962 -- XTCE RTF issues From: "Jonathan gal-edd" To: "Ed Shaya" Cc: "Juergen Boldt" , xtce-rtf@omg.org User-Agent: SquirrelMail/1.4.4 > ED, You asked for our input so you need to be a little more receptive. Comments like" There is a single guiding principle that the XML/database world has> agreed upon as The Way. It was the point of departure between SGML,> the predecesor of XML, and XML, although it was already clear to the > database gurus for some time. The overaching rule is "separate display > requirements from pure information." XCTE is for exchange of data ( commands and temlemtry) this is a well defined subset. If you are planning to turn XCTE to the MIssion PRD plese let us know. XCTE is too complex, work with us to simplify it. Thanks >>> > There is a single guiding principle that the XML/database world has > agreed upon as The Way. It was the point of departure between SGML, > the predecesor of XML, and XML, although it was already clear to the > database gurus for some time. The overaching rule is "separate display > requirements from pure information." That is, one is to allow the > "database schema" (broadly interpreted) to be totally independent of > the manner or purpose of data presentation AND of data collection. > By this principle one allows for the greatest freedom in reuseability > of information even into unforseen uses. > In practice what does this mean? It means that schema should be > designed to hold the facts and just the facts without concern for > specific usage nor data collection procedure or purpose. It should be > technically correct and complete and that is all. There should be an > effort for it to contain no holes where information could exist but has > no place to go. If such info is discovered, XML provides for easy > extension to immediately provide additional containers. > But, what about complexity and the shear enormous size of the > resulting schema? How is anyone to fill out or find what they want in > such weighty schema? The answer to that is ALWAYS by transformation in > the display. Typically, one creates multiple stylesheets to fill-in > forms or Word Templates etc. for various user types to fill in the > info. So one could have XXXLite/Med/Full forms for different data > collectors to use depending on their needs. Likewise, for different > views on the data, one would have XXXLite/Med/Full display pages. > Several browser have pull down menus to select the stylesheet or one can > provide the choice in the displayed page itself. > But creating multiple schemas for the same topic may lead to disastrous > results. There will inevitably be some group that wants something > between lite and medium who may create the medium-lite schema, etc. > Extensions may be added to one of non-full versions but not to the full > version and so they become unsynchronized. Worst of all, extensions to > Lite or Med may be added to hold a few items that are in Full, but do so > in a way inconsistent with Full. > It just is not necessary nor wise. Our instincts to create a full > robost technically correct schema was right on. Where it can be > logically modularized by topic, it should be. Schemas inheriting it > should accept the whole thing or whole modules. Then, it is just fine > to implement only certain parts of it, as needed, by creating simple > forms and/or display stylesheets for just the elements reasonable for > the specific application or use. > We might have arranged it such that a Med is simply composed of > includes/inheritance of a Lite, and a Full inherits from Med and then > extends that, and then I would say that this may not be too harmful > since it is logically still a single schema. But, the above problems > can still arise and is simply modularizing along an axis that is > unnecessary. > > Ed Date: Mon, 12 Sep 2005 13:49:49 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en To: xtce-rtf@omg.org Subject: RE: RTF issues Too broadbased and too complex are two different concepts. Too broadbased was covered in a different issue (#8959). The issue of complexity is usually tighed more closely with depth. And my point is that the depth must remain. If it can be retained with greater simplicity then fine, but it must remain. Ed Jonathan gal-edd wrote: ED, You asked for our input so you need to be a little more receptive. Comments like" There is a single guiding principle that the XML/database world has> agreed upon as The Way. It was the point of departure between SGML,> the predecesor of XML, and XML, although it was already clear to the > database gurus for some time. The overaching rule is "separate display > requirements from pure information." XCTE is for exchange of data ( commands and temlemtry) this is a well defined subset. If you are planning to turn XCTE to the MIssion PRD plese let us know. XCTE is too complex, work with us to simplify it. Thanks There is a single guiding principle that the XML/database world has agreed upon as The Way. It was the point of departure between SGML, the predecesor of XML, and XML, although it was already clear to the database gurus for some time. The overaching rule is "separate display requirements from pure information." That is, one is to allow the "database schema" (broadly interpreted) to be totally independent of the manner or purpose of data presentation AND of data collection. By this principle one allows for the greatest freedom in reuseability of information even into unforseen uses. In practice what does this mean? It means that schema should be designed to hold the facts and just the facts without concern for specific usage nor data collection procedure or purpose. It should be technically correct and complete and that is all. There should be an effort for it to contain no holes where information could exist but has no place to go. If such info is discovered, XML provides for easy extension to immediately provide additional containers. But, what about complexity and the shear enormous size of the resulting schema? How is anyone to fill out or find what they want in such weighty schema? The answer to that is ALWAYS by transformation in the display. Typically, one creates multiple stylesheets to fill-in forms or Word Templates etc. for various user types to fill in the info. So one could have XXXLite/Med/Full forms for different data collectors to use depending on their needs. Likewise, for different views on the data, one would have XXXLite/Med/Full display pages. Several browser have pull down menus to select the stylesheet or one can provide the choice in the displayed page itself. But creating multiple schemas for the same topic may lead to disastrous results. There will inevitably be some group that wants something between lite and medium who may create the medium-lite schema, etc. Extensions may be added to one of non-full versions but not to the full version and so they become unsynchronized. Worst of all, extensions to Lite or Med may be added to hold a few items that are in Full, but do so in a way inconsistent with Full. It just is not necessary nor wise. Our instincts to create a full robost technically correct schema was right on. Where it can be logically modularized by topic, it should be. Schemas inheriting it should accept the whole thing or whole modules. Then, it is just fine to implement only certain parts of it, as needed, by creating simple forms and/or display stylesheets for just the elements reasonable for the specific application or use. We might have arranged it such that a Med is simply composed of includes/inheritance of a Lite, and a Full inherits from Med and then extends that, and then I would say that this may not be too harmful since it is logically still a single schema. But, the above problems can still arise and is simply modularizing along an axis that is unnecessary. Ed