"record" link relation and target resource media type hints

[dret]

looking at http://www.idpf.org/epub/vocab/package/link/ it seems that saying "The media type of the record must be identified in the media-type attribute [Packages3] when this relationship is specified." for the record relation is too strong.
after all, it might be possible for a publisher to publish all record types they support at the same URI, supporting HTTP conneg.
also, clients can never depend on the URIs really returning the media type, as that may change over time, and as such any media type info is just an unreliable hint anyway: https://github.com/dret/hyperpedia/blob/master/concepts.md#target-resource-hints
what about making that a MAY and making it clear that the actual media type is a runtime issue, and that HTTP conneg can be used to communicate client expectations?

[mattgarrish]

The wording of the definition has changed since this issue was opened (normative statements were removed), but the issue isn't specifically with this property.

EPUB 3 has always made the media-type required, although since these aren't publication resources I'm not sure it's a necessary requirement. If we make it optional for records, though, it becomes optional for all other link types.

I personally don't have a problem with changing, as I expect people will still specify for linked resources that aren't dynamically served and it fixes this obvious bug. It won't break existing content, either.

@tkanai, @laudrain, @TzviyaSiegman thoughts on this?

[laudrain]

I'm for media-type required on link record.

[TzviyaSiegman]

I don't think this will break anything, so I think it's ok.

[mattgarrish]

What if we keep it required to specify on all resources inside the container but optional for remote?

[TzviyaSiegman]

That is what I was trying to formulate before I had coffee. Optional for remote is good.

[laudrain]

Good for me too.

[mattgarrish]

@tkanai how does this fit with your work on retrieving remote records/resources?

Is it okay, or should we be more restrictive and say that authors should only omit a media type on links when content negotiation with a server is expected?

[dret]

On 2016-07-11 16:32, Tzviya wrote:

That is what I was trying to formulate before I had coffee. Optional for
remote is good.

requiring a media type with a link relation type is an anti-pattern.
this is what link hints can be used for. RFC 5988 specifically disallows
this kind of over-constraining. even if you do not plan on registering
the link relation type, designing it according to RFC 5988 is a good idea.

https://tools.ietf.org/html/rfc5988#section-4.1

"Registered relation types MUST NOT constrain the media type of the
context IRI, and MUST NOT constrain the available representation media
types of the target IRI."

[mattgarrish]

There's no http response for resources inside the container. If you don't specify a media type, then the reading system can't learn anything about the resource except by opening it and parsing the content, and resources inside the container are never dynamically served. That's always been what the media-type was intended to avoid for resources inside the container.

The media-type attribute doesn't constrain the relationship. We're not saying that there is a limited number of media types that can be associated with an epub publication based on the relationship. But if the resource is inside the container, you need to specify its media type for the reason above.

[dret]

On 2016-07-11 18:40, Matt Garrish wrote:

The media-type attribute doesn't constrain the relationship. We're not
saying that there is a limited number of media types that can be
associated with an epub publication based on the relationship. But if
the resource is inside the container, you need to specify its media type
for the reason above.

sounds good, and i think i misunderstood that you wanted to constrain
the link relation type to always link to a resource of a fixed media
type. that's the anti-pattern.

having a link hint with a media type actually is a good pattern:

https://github.com/dret/hyperpedia/blob/master/concepts.md#target-resource-hints

the only gotcha there is that it should be treated as a hint and not a
guarantee: implementations can expect the hinted media type, but should
be able to deal with the situation when they retrieve something else.

[tkanai]

The meta HTTP protocol is designed to be used with HTTP Content negotiation, so making the media-type optional will not introduce any changes. Actually even if it is required, most of them will use 'media-type="/" ', so I agree with @dret and we should make it optional. For local resources, are there any issues if it is asked to list it up on the manifest?

[mattgarrish]

Linked resources aren't publication resources so they don't have to be listed in the manifest, and typically aren't. That's why there's also a media-type on the link, just like for manifest items.

The media type of items in the container is static and always known (by the author), so it's not really an onerous requirement to keep it required.

[tkanai]

I see. The point is whether metadata is a publication resource or not. I personally think it isn't, but since nav doc is recognized as a publication resource, it might be a good idea to say that metadata document is a publication resource, so that RSs will not necessary to introduce a new method to retrieve the local file.

[laudrain]

It depends on the EPUB author to say if a metadata record is a publication resources.
We should keep the idea that they are not always publication resources.
So that, if not, they are not subject to Core Media Type requirements.

[mattgarrish]

I agree it's an odd case now that we're encouraging reading system use of metadata records without them being publication resources. We can avoid the CMT problem by declaring the package metadata a fallback.

There's a legacy problem if we change, though, since existing 3.0 content uses the link attribute already.

I'm wondering if the media-type attribute on manifest items should also be optional on remote resources, too. Now that we explicitly allow scripts to retrieve remote data, it seems like we have the same pending problem.

[mattgarrish]

The problem for making optional for manifest items is that it complicates verification of CMTs and fallbacks. Not an issue for script data and fonts, that don't require fallbacks, but for audio and video, that do.

[laudrain]

Shouldn't we keep it simple, probably as it is in 3.0.1?

[mattgarrish]

Yes, I'm thinking it doesn't matter now as I wake up. A reading system needs to know the media types, but a script will never see the manifest. Since script data doesn't require a fallback, it doesn't matter what the author puts in the media type.

[mattgarrish]

Proposed solution:

Make the media-type attribute on link elements optional when the referenced resource is located outside the epub container.

[mattgarrish]

I've updated the specification to make the attribute conditionally required[1] and added the following paragraph:[2]

The media-type attribute is optional when a linked resource is located outside the container, as more than one media type could be served from the same IRI. The attribute is required for all resources inside the Container.

Please close this issue if no other changes are required.

[1] https://rawgit.com/IDPF/epub-revision/master/build/31/spec/epub-packages.html#elemdef-opf-link
[2] https://rawgit.com/IDPF/epub-revision/master/build/31/spec/epub-packages.html#attrdef-link-media-type