Dave Pawson wrote:
> Any changes to it?
> an application profile is a set of metadata elements, policies, and
> guidelines defined for a particular application.
>
> The elements may be from one or more element sets, thus allowing a
> given application to meet its functional requirements by using
> metadata from several element sets including locally defined sets.
>
>
> I'm happy with the first para as most general.
> The second para is too constraining? That could take 'profile' out
> of the domain of application usage which, IMHO, is wrong.
>
> Definition: "an application profile is a set of policies, and
> guidelines defined for a particular application."
>
> Removing the metadata aspect gives a workable definition
> which I think it usable for ODF?
A couple of comments. The first paragraph has the use of "application
profile". This seems to suggest an "OpenOffice.org Profile", "K-Office
Profile", etc. I think the general feel for the profiles is that they
define what aspects of the standard are to be tested. For instance, a
"printing profile", or "application of styles" profile. Basically
making the tests application agnostic. (where application means a
software program in this case).
Perhaps a better phrase there is "Testing profile"? And a "testing
profile" is then assumed to be application, document, or standard
specific. But I'd leave that out of the final paragraph so that we
don't restrict the TC inadvertently.
Also, my understanding of a profile is that it would be a little more
than policies and guidelines. It would also define what is being tested
(restrictions?). For instance, if a test was targeting the accuracy of
the math formulas within a spreadsheet, then the environment has been
defined to be related to spreadsheets (not word documents, or
presentations), and that only the forumlas are being tested...
Taking those into account the first paragraph may become:
"A testing profile is a set of policies, guidelines, and restrictions
defined for a particular test."
But this is getting kind of nit-picky.. :)
The second paragraph isn't really needed, I think. I see it more as a
supporting bit to help define what a "metadata element" is. If we
assume "metadata elements" are encompassed by policies, guidelines
and/or restrictions, then I don't think we need to include that wording.
Shawn
