[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded
A few of us ebXMLRegistry folks are working on a Technical Note, in partnership with the e-gov folks) to describe how a Data Dictionary populated with elements from multiple schemas (cum forms) allows users to discover commonality and promotes reuse (for new schemas). Given the ebxmlRegistry also supports role-based associations we can discuss further when there is a lull in activities :-} . regards carl <quote who="Rex Brooks"> > Yup, We are definitely having an epidemic of agreement today. Also if > you look at NIMS-90, there's a bleep load of forms in there. That's > why I said a data dictionary could be all that is really needed, with > perhaps a table of equivalencies for organizational charts or > roles/responsibilities and rights/permissions.. > > Ciao, > Rex > > At 2:11 PM -0600 4/1/04, RTorchon@eteam.com wrote: >>I don't feel it is the realm of this TC to specify display >>mechanisms. These forms can be accomplished in a variety of ways on >>the web( HTML, PDFs, xForm, java, active x, etc). Plus don't rule >>out any client side applications. >> >>Also, targeting just one form is really not a solution. ICS consists >>of a methodology and a medley of forms( and versions of the same >>form that are vastly different in some cases), some which relate to >>others and some which stand alone. Together they make a system. >> >>We should retrench and make sure we all understand ICS and our >>approach in general. NIMS is sufficiently vague that the standard >>has yet to be defined. >> >>Rob >> >> >>------------------------------------------- >>Rob Torchon >>Vice President, Engineering >>offc: (818) 932 0660 x220 >>fax: (818) 932 0661 >>cell: (805) 551-6232 >> >> >>"Bullard, Claude L (Len)" <clbullar@ingr.com> >> >>04/01/2004 01:40 PM >> >> To: "'R. Allen Wyke'" <emergency-tc@earthlink.net> >> cc: emergency@lists.oasis-open.org >> Subject: RE: [emergency] Groups - ICS-201-draft0.2.xsd >> uploaded >> >> >> >>I am saying don't normatively associate any spec with any other spec >>unless you have to. That's all. Don't let me confuse you because >>I don't have time to look into ICS. I was responding to Rick >>being uncomfortable with specifying XForms. >> >>XForms is an explicit application language. There are alternatives >>to implementing XForms so you should be uncomfortable with that choice. >> >>Is the process specification meant to be executable or >>only an abstraction of a process that can be implemented >>differently? Do you *need* a process specification or is >>it informative material provided to help other implementors? >> >>Dare to do less in cases where doing more forces you to >>make choices for the implementors that they can better >>make for themselves. Do more if the chances are good >>that without the extra work, the specification can't >>be implemented interoperably at all. Be very certain >>about interoperation: systems interoperate; data is >>portable. So if you spec interoperations normatively >>you are designing the system, not the data. >> >>len >> >>-----Original Message----- >>From: R. Allen Wyke [mailto:emergency-tc@earthlink.net] >>Sent: Thursday, April 01, 2004 1:33 PM >>To: Bullard, Claude L (Len) >>Cc: emergency@lists.oasis-open.org >>Subject: Re: [emergency] Groups - ICS-201-draft0.2.xsd uploaded >> >> >>Ok, so are you agreeing or disagreeing with what I proposed? It sounds >>like you agree that we should not attempt to define an XSD (schema) for >>ICS 201, but then you mention preparing a process spec and not address >>the front end (GUI), which is what I *think* we can do with XForms. Or >>are you saying that even touching this with a 10 foot pole (ie: XForms >>too) is way to close? >> >>Just wanting to make sure I am not misunderstanding. Personally, I >>could go either way. I just know that I have a comfort issue with the >>XSD. Jury is out on the XForms idea - it was just a thought that I felt >>was better than defining an XSD. >> >>On Apr 1, 2004, at 2:25 PM, Bullard, Claude L (Len) wrote: >> >>> I agree with Rick. Don't open liaisons or set dependencies >>> on other specifications and standards unless absolutely necessary, >>> meaning, your specification can't be used without them. >>> >>> 1. Your specification will be tied to the evolution of the >>> other specification, and >>> >>> 2. It might lose. >>> >>> len >> >>To unsubscribe from this mailing list (and be removed from the >>roster of the OASIS TC), go to >>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php. > > > -- > Rex Brooks > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth > W3Address: http://www.starbourne.com > Email: rexb@starbourne.com > Tel: 510-849-2309 > Fax: By Request -- Carl Mattocks co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC CEO CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart Compendiums (AOL) IM CarlCHECKMi
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]