Re: placeholder test files

Hi Shane,

Tim, Janina, and I uploaded a number of new schema definitions for the
various body objects yesterday. Our thinking is that the definitions would
be used to test the body object and showcase exactly what the object is
with respect to the Annotation vocabulary.

We've also developed what we think is a good logical flow diagram for the
test of the body object (see attached flow diagram). Although in
retrospect, we probably want to test the *target* key first since, if it's
absent then we already know that the annotation isn't valid or well-formed.
We can reuse the attached flow diagram for target objects simply by
eliminating the check for the *value* key (i.e., the TextualBody case) from
the diagram.

Another thing to note about the uploaded definitions--we've adopted a
standardized and simple scheme for titles and descriptions.

Tim will likely follow up this email later this afternoon with additional
details. Will likely discuss some of this on Friday's call.

Regards,

Jacob




_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
School of Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

On Sun, Jul 17, 2016 at 9:30 AM, Shane McCarron <shane@spec-ops.io> wrote:

> So... it turns out that the prefix "stub-" is reserved in WPT.  I am not
> sure for what, but it is a special class of test files that can't currently
> be selected from the UI.  So when I create the empty test files that need
> populating, I am going to use the prefix "ph-" for placeholder.
>
> On a related note, the result of NOTRUN in WPT literally means that a test
> was created and then nothing was run about it.  I am going to have the ph-*
> tests do this so they show up in our reporting but.... I am sure that is
> not what NOTRUN was intended for and we might get some pushback from the
> powers that be.  Whoever they are.
>
> --
> Shane McCarron
> Projects Manager, Spec-Ops
>