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, 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)" <>
>>
>>04/01/2004 01:40 PM
>>
>> To: "'R. Allen Wyke'" <>
>> cc:
>> 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:]
>>Sent: Thursday, April 01, 2004 1:33 PM
>>To: Bullard, Claude L (Len)
>>Cc:
>>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:
> 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
