There were problems with the preview links... here is an alternative, hopefully will keep on working:

• For EPUB 3.3 Reading Systems:
  • Preview
  • Diff

If I am not mistaken, custom attributes are defined in EPUB 3.3 and then described in EPUB 3.3 RS

Yes, but this is only because it would otherwise be invalid to have custom attributes in xhtml content documents -- although allowed by xml, they aren't an officially recognized extensibility mechanism, so you have to extend html to allow other attributes.

We don't need to do anything special to allow authors to use custom properties in the package document as it's no different than using any other metadata vocabulary. You just have to define a prefix.

Sorry. I think that almost everything in 6.1.5 Custom Properties of EPUB 3.3 RS and 4.1.1.7 Custom Attributes is irrelevant to the conformance requirements of EPUB 3.3 RSes.

But we might want to have something like "Reading Systems MAY behave differently due to custom attributes, as long as they satisfy the requirements in this specification." in 4.1.1.7 of EPUB 3.3 RS. We might want to have something similar about custom properties in EPUB 3.3 RS.

6.1.5 and 4.1.1.7 have four sentences beginning with "Vendors may". I think that these sentences should be reformulated as requirements on data and should then be moved to EPUB 3.3. In the case of custom properties, probably in D.1.6.

I've tried to rework the requirements in the latest commit so that they can exist on the authoring side.

I've also restructured the RS spec to match the new layout control section of the core spec (i.e., grouped fxl and reflowable properties). Nothing has changed in those sections; only the custom properties section that now follows them is new to this PR.

@mattgarrish

Thanks. I'm still proofreading it. It appears that "diff" screwed up. ;-(

It appears that "diff" screwed up. ;-(

The reading system diff/preview links had a typo in the branch name. I've fixed them in the first comment, so they should work now.

(Oh, and I see @iherman already caught the problem yesterday in his comment.)

In the section "Custom attributes" in EPUB 3.3 Core,

Reading System developers may introduce ..

To facilitate this experiment, EPUB Creators MAY ....

I would like to reformulate these paragraphs as requirements on XHTML content documents. After all, we cannot create a test for testing developers.

Here is my proposed rewrite.

XHTML content documents MAY contain custom attributes, which are attributes of foreign namespaces...

I do not think that we should mention the purposes of custom attributes. If we do, it will become unclear whether or not custom attributes NOT FOR RENDERING are allowed.

Such attributes are considered to be part of the default namespace (...).

I was heavily involved in the design of XML namespaces, but the term "default namespace" continues to cause headaches to me. Do we lose something by dropping this sentence? I am not sure if this sentence correct.

After all, we cannot create a test for testing developers.

Well, I was going to argue that we're moving away from an extension mechanism solely for RS developers, which is what this was only supposed to be, to a mechanism that can be exploited for any purpose, but it seems epubcheck just blanket allows any attributes in foreign namespaces...

Do we lose something by dropping this sentence?

Can we work around it by saying:

XHTML Content Documents MAY contain custom attributes, which are prefixed [XML-NAMES] attributes whose namespace URL does not include either of the following strings in its domain [URL]:"

(edit: reworded slightly from original because "provided" left the definition of "custom" unclear.)

Can we work around it by saying: ...

Yes, this rewrite works.

After all, we cannot create a test for testing developers.

Well, I was going to argue that we're moving away from an extension mechanism solely for RS developers, which is what this was only supposed to be, to a mechanism that can be exploited for any purpose, but it seems epubcheck just blanket allows any attributes in foreign namespaces...

An earlier version of ISO/IEC 29500-2 (OOXML) contained lots of sentences beginning with "Producers shall", "Consumers may", "Format designers shall", and so forth. I rewrote most of them in the latest version as requirements on data. I firmly believe that data conformance, which is enforceable by examining data, is far better than application conformance, which is hard to test.