What is the difference between "Well-formed" and "Well-formed and not valid"?

[RvanVeenendaal]

When running JHOVE 1.34 against the file format corpus, I get "Well-formed" and "Well-formed and not valid" results. Please help me understand what the difference is.

If there is no difference I'd like to suggest choosing one of the two messages. I'd choose the most explicit: "Well-formed and not valid". If there is a difference, I'd like to suggest updating the "Well-formed" message to "Well-formed and XYZ". Where XYZ is one or two words clearly differentiating this message from "and not valid".

I noticed that the "Well-formed" results are usually at XML files like these

• 280.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
• 281.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
• 333.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
• 334.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
• DROID_SignatureFile_V67.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
• epub-ibooks-signature-file.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
• Rocket-Book-format-v1.0-signature-file.xml | 1.34.0 | XML-hul | 1.5.5 | Well-Formed
  and that "Well-formed and not valid" can be present at various other formats, such as EPUB, HTML, PDF and TIFF.

[samalloing]

Hi Remco,

To keep the XML example, Well-formed means the XML has some rules about the structure like you need to have an open and a close root element. If that is missing, then the XML is not well-formed. If the XML schema doesn't validate, then the XML is not valid. The structure can be fine, but the semantics can be wrong (for example a certain element is mandatory. If you schema mandates a title element and it is missing then it isn't valid)

I hope this makes it a little bit clearer. In other formats the difference between well-formed and well-formed and not valid is less clear. That is why the well-formed only is not used that much (maybe it isn't I didn't check)

Sam

[ross-spencer]

I follow Sam's lead with the XML definition as a guide. I tackle it similarly in an old OPF blog: https://openpreservation.org/blogs/what-is-the-point-the-motivation-for-adopting-different-tools-inside-the-digitalpreservation-workflow/#well-formed-valid

I also have two shorter definitions on my DP glossary:

• well-formed
• valid

I think today, for me, well-formed is always about structure, and validity is about structure and semantics.

I think structured text formats brought well-formedness to the fore because you can always create well-formed structured text, and that does need to be measured before then trying to parse and validate such documents for any other rules they should encode.

[RvanVeenendaal]

Thanks for your responses. I see that I was unclear in my question. Let me rephrase it: What is the difference between "Well-formed" and "Well-formed and not valid" if JHOVE can also report “Well-formed and valid”? Logic tells me that “Well-formed and (not) valid” should be enough to report all possible states for a Well-formed object. But an object can also be just “Well-formed”. What am I missing?

[ross-spencer]

Portico also have a good definition of each of the states here: https://www.portico.org/wp-content/uploads/2023/07/Portico-Journal-Submission-Guidelines.pdf

But I guess I'm still not sure of the question, is it more a discussion about whether JHOVE reports on too many states? Or the states might not be logically consistent between formats?

I am just looking at the source code and one thing it might be good to follow up on this issue with is expanding the getting started guide to include more negative states as it only looks at positive JHOVE outcomes:

• https://github.com/openpreserve/jhove/blob/integration/docs/getting-started/index.md#introduction

Some additional user-facing sample files and examples might also be useful for making the states more apparent in future too.

In the source code, I think there's some clarification that the state is reported: well-formed but not valid and not well-formed and not valid.

Looking for references for how it is applied we have the following that might be illiminating:

jhove/jhove-modules/jpeg-hul/src/main/java/edu/harvard/hul/ois/jhove/module/JpegModule.java

Lines 87 to 90 in 7595dd5

	* JPEG file formats which are JPEG streams are treated here. A JPEG stream
	* which isn't one of the known file formats will be regarded as well-formed,
	* but not valid. To be valid, a file must conform to one of the following:
	* JFIF, SPIFF, and JPEG/Exif. Other formats may be added in the future.

jhove/jhove-ext-modules/src/test/java/org/ithaka/portico/jhove/module/EpubModuleTest.java

Lines 491 to 497 in 7595dd5

	/**
	* This epub has missing fonts. Should be well formed but not valid. File
	* derived from:
	* https://github.com/KBNLresearch/epubPolicyTests/tree/master/content/epub20_missingfontresource
	*
	* throws @Exception
	*/

jhove/jhove-ext-modules/src/test/java/org/ithaka/portico/jhove/module/EpubModuleTest.java

Line 618 in 7595dd5

// well formed but not valid because can't parse encrypted file to confirm

jhove/RELEASENOTES.md

Lines 1438 to 1440 in 7595dd5

	2. Destinations defined by indirect references to non-existent objects
	are assumed to have the value "null". Files containing such
	destinations are reported as "well-formed, but not valid".

But yeah, not sure if any of that is useful. I think this is something we've probably all explored at individual institutions and have notes and samples for, but we'd be benefit from centralizing this in a JHOVE resource more formally.

[carlwilson]

@RvanVeenendaal, I've taken a look at the code. The code that assigns the strings assumes that the isValid method returns either a TRUE or FALSE value, here's a typical implementation:

            switch (info.getWellFormed()) {
                case RepInfo.TRUE:
                    wfStr = "Well-Formed";
                    break;

                case RepInfo.FALSE:
                    wfStr = "Not well-formed";
                    break;

                default:
                    wfStr = "Unknown";
                    break;
            }
            // If it's well-formed, append validity information
            if (info.getWellFormed() == RepInfo.TRUE) {
                switch (info.getValid()) {
                    case RepInfo.TRUE:
                        wfStr += " and valid";
                        break;

                    case RepInfo.FALSE:
                        wfStr += ", but not valid";
                        break;

                    // case UNDETERMINED: add nothing
                }
            }

Now info.getValid() returns an int, NOT a boolean, and the intended values are:

    /**
     * Validity flag. A ternary variable which can have a value
     * of TRUE, FALSE, or UNDETERMINED.
     */
    private int _valid;
    
    /** Values for _valid */
    public final static int TRUE = 1,
        FALSE = 0,
        UNDETERMINED = -1;

Two things to note here. The variable _valid isn't assigned on declaration, so it starts as 0 (FALSE), and there is the wild-card UNDETERMINED value. Either case would lead to the truncated "Well-formed" message you're seeing. The lack of a message infers that the validity is UNDETERMINED, and should say so if that's the case IMO.

[carlwilson]

Investigating further, only the EPUB, WAV and XML modules use the UNDETERMINED value. For XML it means that the document was well-formed, but no schema declaration was present. The modules listed are consistent with your results.