search

w3c / pub-manifest

W3C Publication Manifest
https://w3c.github.io/pub-manifest
Other
7 stars 16 forks source link

An extra extension point may be needed? (Additional context files) #186

Closed iherman closed 4 years ago

iherman commented 4 years ago

It is a possible that a particular profile would need an additional JSON-LD context file (although we do not have an example right now). Wouldn't it be necessary to add such an extension point in the processing steps?

The proper place would be after step (3) in §7.4.

iherman commented 4 years ago

Strictly speaking, a context check could be done in point (10) of §7.4.. However, a missing context is a fatal error, and this should be true for a profile as well...

mattgarrish commented 4 years ago

I think we have to incorporate such a check into step 4, the one that determines what profile the manifest conforms to.

We can't do it before without that knowledge, and we can't wait until Step 9 because we toss the context when we normalize the data in Step 6.

(Is there any reason to retain the context strings in the internal representation? We throw out the context because we've already incorporated lang/dir information into each property, but the side effect is this information is lost. I can't think of one, as it seems like the UA will already be aware of the contexts if it needs them by virtue of recognizing the profile.)

iherman commented 4 years ago

I think we have to incorporate such a check into step 4, the one that determines what profile the manifest conforms to.

We can't do it before without that knowledge, and we can't wait until Step 9 because we toss the context when we normalize the data in Step 6.

Right. But I would slightly modify this by saying that it should be a separate point after step 4. In all other places the call out to the extension is listed as a separate step; it is better to be consistent.

(Is there any reason to retain the context strings in the internal representation? We throw out the context because we've already incorporated lang/dir information into each property, but the side effect is this information is lost. I can't think of one, as it seems like the UA will already be aware of the contexts if it needs them by virtue of recognizing the profile.)

I could (but hardly) imagine a processor that would want to use the information within a JSON-LD context but... this really seems to be very theoretical. If I was to write such a processor, I would throw out our algorithm altogether and use a bona fide json-ld processor... So, no, I do not really see any reason either.

mattgarrish commented 4 years ago

I would slightly modify this by saying that it should be a separate point after step 4.

Ya, that's what I was initially going to do, but then it's sort of strange to have an extension for context strings two steps after checking them generally for manifests, and then have another extension step for "everything else" profiles need to check five steps later.

That's why I've been pondering whether there is a better way to order/structure the first few steps. I was thinking initially we could fob off additional contexts as part of checking conformance to a profile. Not perfectly logical to wed the two things, but avoids the obvious duplication.

What we want is to get the profile first, but if we do that then we're looking into a json document that we aren't yet sure even is a publication manifest. That's flawed logic, too.

Kind of an intractable problem. The verbose approach may be the only solution.

At any rate, we should mention in the context section that profiles can add additional contexts so we have something tangible to link the step to.