Make the return value of "Parse metadata" consistent

[fmarier]

The output of this algorithm should be the same in all three
cases:

• the empty string
• a list of one or more metadata with unrecognized hash functions
• a list of one or more metadata with invalid ni URI

This change makes the last two cases match the output of the first.

[fmarier]

This is the opposite of #120.

[devd]

I am not sure if the right thing is to return empty value from algorithm in all three cases or to treat all three as empty in the spec. The different values could allow for flexibility in the future, maybe? And I imagine UAs might want to implement that anyhow to differentiate warnings in the console. WDYT @mozfreddyb @metromoxie

[joelweinberger]

I don't feel too strongly either way. I think the point about warnings is good, but UAs could, of course, juts do that mid-algorithm anyway.

[fmarier]

@devd Speaking for the Firefox implementation, the algorithm in the spec is not really what I've implemented anyways. I do check for various ways in which things fail to be valid.

However, I think these are implementation details and that the spec algorithm can omit these details and focus on being simple to understand and reason about.

[mozfreddyb]

I hope that users and authors in our spec audience will outnumber us user agent people. So maybe we should optimize for clarity, not for implementation?

(I was going to say priority of constituencies, but forgot the exact term.)

[mikewest]

I'd agree that you should optimize for clarity, but I would tentatively suggest that the prose in your specification is for authors and users, and it should explain enough for them to understand both the intent and impact of the feature. The algorithms are probably best written with implementers as the target audience.

[devd]

lets merge this for now and then take another edit pass at it later. I imagine we will need to edit the use of ni:// URIs too.