toc.ncx required attributes missing? mimetype wrong?

[bobdc]

epubcheck is very useful, but it's giving me two error messages that I
don't understand:

1. toc.ncx(5): required attributes missing

Line 5 of my toc.ncx looks like this:

<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1">

The toc.ncx file is valid to the http://www.daisy.org/z3986/2005/ncx-2005-1.dtd
DTD, which doesn't declare any attributes for the ncx element besides
xmlns, version, xml:lang, and dir, which are both #IMPLIED. (Even when
I add the two of them, I still get the same error message.) Is
epubcheck using a different DTD?

2. My mimetype file consists of the following single line with a
carriage return at the end:

application/epub+zip

epubcheck gives me this error message:

mimetype contains wrong type (application/epub+zip expected)

Why would it complain about this mimetype file?

thanks,

Bob

[garth...@gmail.com]

Hello Bob,

Comments below...

On Jan 6, 9:27 am, bobdc <bob.ducha...@gmail.com> wrote:
> epubcheck is very useful, but it's giving me two error messages that I
> don't understand:
>
> 1. toc.ncx(5): required attributes missing
>
> Line 5 of my toc.ncx looks like this:
>
> <ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1">
>

> The toc.ncx file is valid to thehttp://www.daisy.org/z3986/2005/ncx-2005-1.dtd

> DTD, which doesn't declare any attributes for the ncx element besides
> xmlns, version, xml:lang, and dir, which are both #IMPLIED. (Even when
> I add the two of them, I still get the same error message.) Is
> epubcheck using a different DTD?

You should be able to "fix" this with the addition of
'xml:lang="en"'. The DTD has "lang" as IMPLIED, but we're currently
enforcing it as non "<optional>" from our RNG version of the DTD.
There is a proposed fix for this, but for now you can just add the
attribute, I think.

> 2. My mimetype file consists of the following single line with a
> carriage return at the end:
>
> application/epub+zip
>
> epubcheck gives me this error message:
>
> mimetype contains wrong type (application/epub+zip expected)
>
> Why would it complain about this mimetype file?

From the OCF specification:

<quote>
The first file in the ZIP Container MUST be a file by the ASCII name
of 'mimetype' which holds the MIME type for the ZIP Container (i.e.,
"application/epub+zip" as an ASCII string; no padding, white-space or
case change). The file MUST be neither compressed nor encrypted and
there MUST NOT be an extra field in its ZIP header. If this is done,
then the ZIP Container offers convenient "magic number" support as
described in RFC 2048 and the following will hold true:

The bytes "PK" will be at the beginning of the file
The bytes "mimetype" will be at position 30
The actual MIME type (i.e., the ASCII string "application/epub+zip")
will begin at position 38
</quote>

My guess is that the mimetype file is either not first in the ZIP
archive or it is compressed. If you do a binary dump of the OCF
(.epub) -- "hexdump -C foo.epub | more" -- you should see "application/
epub+zip" starting at byte 38. The string "mimetype" should directly
precede that, starting at byte 30.

Take a look at "http://www.idpf.org/forums/viewtopic.php?
t=85&sid=feed5a1cbfebd446aaa811b65c7ab380" for various hints on
creating OCF files.

[bobdc]

1. I swear I tried that before ("Even when I add the two of them, I
still get the same error message") but perhaps that was before I
realized that I needed the -d switch when I used zip. This time it
worked.

>our RNG version of the DTD

"Your" version? Isn't the point of a standard that we all use the same
publicly available version? (Trang certainly isn't going to make an
IMPLIED attribute required while converting a DTD to an RNG file.)

This is really a bad idea for you guys. I like epub as a format, but
if you review the comments of people who distrust it, it's because
they consider it an Adobe thing and not a public standard, like XMP.
If "EpubCheck development was largely done at Adobe Systems," as
http://code.google.com/p/epubcheck/ tells us, and a development tool
like epubcheck has dependencies on documents that are not publicly
available, it gives the anti-epub people another reason to be
suspicious of Adobe's commitment to making epub an open standard. I
would fix this as soon as possible, and meanwhile, I would make the
internal RNG version available publicly.

2. I removed the carriage return and it was fine.

thanks,

Bob

[garth...@gmail.com]

> >our RNG version of the DTD
>
> "Your" version? Isn't the point of a standard that we all use the same
> publicly available version? (Trang certainly isn't going to make an
> IMPLIED attribute required while converting a DTD to an RNG file.)

By "our" I didn't at all mean altered -- it's just a mechanical
conversion from DTD to RNG (right, Peter?) -- somehow this was not
perfect -- and a fixed version will be up very shortly (if not
already). And, the RNG version *is* public, it's with the source.

Not to worry!

And, re "whose standard" -- epubcheck and the OCF/OPS/OPS (.epub)
files it checks is an IDPF standard. IDPF has quite a broad
membership -- Adobe is a member, but one of many -- it is public
standard, and epubcheck is an open-source tool.

Best,
Garth

[Dave Cramer]

I may be naive, but I never thought of epub as an "Adobe thing." 

I also ran into an inconsistency between the NCX DTD and the RNG version (can't remember exactly, but it was a co-occurence issue). It was easy to sort out after Garth sent me a copy of the rng file. 

Dave Cramer

TexTech, Inc.

[bobdc]

On Jan 7, 7:54 pm, garthcon...@gmail.com wrote:
> it's just a mechanical conversion from DTD to RNG

As you quoted me saying about the program used to make this
conversion,

> > Trang certainly isn't going to make an
> > IMPLIED attribute required while converting a DTD to an RNG file.

After looking around for the source, I realized that the RNG schema is
right there in the jar file, and xml:lang is not optional in that
version, as it is in the http://www.daisy.org/z3986/2005/ncx-2005-1.dtd
DTD, so someone either created the RNG file from a DTD that didn't
conform to the the standard's requirements (see
http://www.niso.org/standards/resources/Z39-86-2005.html#NCXElem) or
else revised the RNG file after making the conversion.

I can work with the schema that I got out of the jar file for now, and
will find epubcheck very useful. I don't mean to complain too much,
but if epubcheck is about checking for conformance to the IDPF
standard, and the epub standard requires (http://www.idpf.org/2007/opf/
OPF_2.0_final_spec.html#Section1.4.1.2 vii) that an NCX be included (I
only just realized that NCX is part of a separate ISO standard), then
epubcheck should check that documents conform to the actual standard.
I look forward to the updated version.

thanks,

Bob

[Markus Gylling]

Hi Bob and all,

I represent DAISY and the ANSI/NISO Z3986 standard, which are the
formal maintainers of the NCX and DTBook grammars.
As far inconsistencies between the (formal) DTD version [1] and the
RelaxNG version in epubcheck, I cant really answer how these occured
(I didnt author the schema thats in epubcheck). However, let it be
clear that IDPFs intent is not to skew the grammar in any way within
OPS, it is intended to be a 1:1 representation of the Z3986 source.

DAISY does provide another NCX RelaxNG grammar [2], that is used by
the official ANSI/NISO Z3986 validator [3]. We could consider dropping
the epubcheck version and using this, however the issue here is that
the [2] grammar does include a lot of domain specific addons (such as
Schematron rules that reference keys for i12n etc). So perhaps we are
best suited to keep the current schema and fix whatever minor probs
remain (such as the fix I just committed to the trunk regarding the
dir and xml:lang attributes).

[1] http://www.daisy.org/z3986/2005/
[2] http://daisymfc.svn.sourceforge.net/viewvc/daisymfc/trunk/dmfc/src/org/daisy/util/xml/catalog/z39862005/ncx-2005-1.rng?view=log
[3] http://sourceforge.net/project/showfiles.php?group_id=73271

Regards,

Markus Gylling
Technical Development Coordinator
the DAISY Consortium
www.daisy.org