Re: reflections on StratML

aargh
Part 3?  had not heard of that yet

I hope you see my point. nothing would prevent anyone from using a subset
of it. but my advice as a systems and web service designer would be
definitely to resolve those
differences into a classy single schema that can be personalized-

I am actually not likely to use my personal plan very much. my goal is to
continue to improvise :-)
but we created one as a test. and maybe one day when it all comes together
I ll look back and
write up the plan retrospectively :-)   I always do that. (what were we
doing?...)

However. the plan started by Carl  for this AI KR CG would be useful as a
collaboration and tracking tool
so I ll work on that

Thanks for the machine readability push

P

On Sun, May 3, 2020 at 9:56 AM Owen Ambur <Owen.Ambur@verizon.net> wrote:

> Paola, thanks for sharing these thoughts.  I'm very glad to hear that you
> intend to draft a plan in StratML format.  As one who has converted
> thousands of plans and about us statements to StratML format, I encourage
> you to start with Part 1.
>
> However, if you use Chris' app, it doesn't matter because it can output
> data in either Part 1 or Part 2 format.  Moreover, if you were to use, my
> (actually Joe Carmel's) XForm for Part 1
> <https://stratml.us/forms/Part1Form.xml>, the file can easily be imported
> into Alain Barbet's XForm for Part 2
> <http://waterland.freeboxos.fr:8009/Part2Form.xml>.  When I create Part 2
> files (which is far less often) that's generally what I do, i.e., create a
> Part 1 file first.
>
> There is no way that I personally am going to give up Part 1 and be forced
> to contend with the additional elements in Part 2 when I do not wish to do
> so.
>
> If others want to focus solely on Part 2, great.  I look forward to seeing
> as many performance plans and reports as they are willing and able to
> produce.  I'd be delighted to see bunches of them ... but based upon
> experience over the past many years, I don't anticipate that happening in
> the near future.  Providing the additional information required for
> performance plans and reports requires a fair amount of work, and until we
> can demonstrate the benefits, it's unlikely many people will be willing to
> so so.  Thus far, I believe I'm the only one.
>
> If and, hopefully, when we are able to get StratML back on the ANSI/ISO
> standards track, potential enhancements to Part 2 will be in order and the
> output of the StratML Committee will depend upon the consensus of the
> participants.  I hope you will be among them.
>
> BTW, StratML Part 3 <https://stratml.us/#Part3> was specified to address
> data requirements implicit in the GPRA Modernization Act
> <https://stratml.us/references/PL111-532StratML.htm> (GPRAMA), albeit in
> a manner generic enough to apply to all organizations worldwide and not
> just U.S. federal agencies covered by the law.  If only one schema could be
> used, a case could be made that it should be the Part 3 schema ... but that
> most likely would mean that it wouldn't be used at all, because it entails
> far more complexity than anyone wants to take on at once -- including U.S.
> federal agencies, who have been directed by law to do so.
>
> Again, I encourage one and all to start with Part 1, but in any event, I
> look forward to seeing your plan, in whatever format you may choose to
> share it.
>
> Owen
> On 5/2/2020 9:00 PM, Paola Di Maio wrote:
>
> Owen
>
> after trying out the stratnav application in a demo last week, , I look
> forward to be working on the stratml plan for this CG
> in the app
>
> My personal opinion as a software/systems engineer. is that the
> distinction between stratML 1 and 2
> is not good. It makes the schema a bit brittle, easily breakable and
> awkward to get ones head and parser around.
>
> The first thing I would do if I had to use it as a standard would be to
> have a single
> schema.
>
> Some of the elements may be mandatory, like hearders and some elements may
> be optional (so that the user
> always have to insert the mandatory elements but can select which optional
> elements they need in their
> instance). This would enhance its robustness and usability
>
> The tool itself may benefit from some tweaking as discussed in offilst
> email
>
> It is only after we see the output of the parser that the schema can be
> fully evaluated and only then we ll know
> if stratml may need additional iterations to be optimized/make it smooth
>
> Thought I would throw my two cents in case you decide to develop it
> further. I think it could be very useful but it
> may need to evolve a bit to fit the use cases
>
> Ill get my hands on the plan as soon as I can. this month I hope
> Hope veryone stays safe
> PDM
>
>