Is this a valid test for prefix mapping?

[iherman]

Is this a valid test for prefix mapping?

[mattgarrish]

I'll open an issue in the main tracker, too, as we should probably find out how reading system devs have interpreted this.

[mattgarrish]

My expectation would be that a RS should open the first version without further ado

Not if I understand you correctly. In that case, you'd no longer have a nav declaration, only some unknown property: http://example.org/#nav

Or does your first version declare a nav without the prefix in another manifest entry? Or are you adding that to your second to make sure the unknown property is ignored?

In any case, you can't test from the rendering whether the default vocabulary URIs are used to resolve the unprefixed properties, or I've not heard of functionality that depends on resolving the value. It's required to ensure that all the CURIEs (er, "datatype properties") resolve to URIs so you don't have a mix of URIs and token values to deal with for internal logic purposes.

In this case, a declaration from the developer is probably all you're likely to get to confirm. I remember asking in the past whether any reading systems did this, and as I recall readium at least used to. I don't know if that's still the case with the new app. @danielweck would know more.

[iherman]

Not if I understand you correctly. In that case, you'd no longer have a nav declaration, only some unknown property: http://example.org/#nav

Or does your first version declare a nav without the prefix in another manifest entry? Or are you adding that to your second to make sure the unknown property is ignored?

No, in the first version the prefix is defined for the default, official URL, ie, http://idpf.org/epub/vocab/package/item/#!

[mattgarrish]

No, in the first version the prefix is defined for the default, official URL

Right, but what does it mean to open the first version when you change the prefix in the second version? The best I can understand is you mean you'll do this:

<package ... prefix="myown: http://example.org/#">

    <item id="nav" properties="myown:nav" href="nav.xhtml" media-type="application/xhtml+xml" />

So you no longer have a nav property declaration unless you've included an unprefixed version in the elided markup.

The first example should be fine in theory, although I expect it will blow up in practice. While there may be some reading systems that expand the properties, I highly doubt it's common practice. That's why you're not supposed to assign prefixes to the default vocabularies. It's a tacit acknowledgement that things will go sideways on you.

Are reading systems required to expand the CURIEs, or is it only a requirement to use the stem if they choose to?

[iherman]

Right, but what does it mean to open the first version when you change the prefix in the second version? The best I can understand is you mean you'll do this:

<package ... prefix="myown: http://example.org/#[](http://example.org/#)">

    <item id="nav" properties="myown:nav" href="nav.xhtml" media-type="application/xhtml+xml" />

So you no longer have a nav property declaration unless you've included an unprefixed version in the elided markup.

I am sorry, I was not clear. I created two EPUB instances: version 1 and version 2. The first EPUB is using the prefix with the official URL, the second EPUB is using it with example.org. What I am saying is that a RS should display the first EPUB just as if the prefix was not used at all because, after all, the prefix is "just" defining what the default URL mapping would do anyway. The prefix is unnecessary, but should not change the behaviour.

The second EPUB should go wrong of course.

[mattgarrish]

What I am saying is that a RS should display the first EPUB just as if the prefix was not used at all because, after all, the prefix is "just" defining what the default URL mapping would do anyway.

If you assume that it's required to resolve the prefix. I don't recall that was ever the intention, but haven't had time to go spec-skimming to see what it says now. It's why values that have some processing expectation either don't have prefixes or have reserved ones, though. The RDFa/CURIE underpinning of the package document wasn't supposed to bleed through into requirements to process that way, only define how you can get to URIs

[iherman]

If it is not required to resolve the prefix, then this should be made clear somehow. The current text suggests (at least for me, but I am of course biased by my RDFa past) that the prefix mechanism is in place in the package document, and the MUST statements in the RS specs certainly suggest the same...

[mattgarrish]

I'll have a look this morning, but I was expecting it was one of those situations where if you resolve the CURIEs, then here are the requirements for doing so.

We never wanted to burden reading systems with that processing, only provide a pathway for moving between our quasi-RDFa and real RDFa. It was also to allow translation between the package metadata and a "real" format in the future with minimal information loss. In that way it's somewhat useful, even though on most days it feels like a lot of bloat to foist on authors and reading systems for processing that's probably not used much in practice.

[iherman]

B.t.w., I tested these on a RS (Thorium) and it failed on version 1. It clearly did not recognize the nav file with the prefix URL.

[iherman]

This has become moot, because the prefix mapping is optional...