OPF attributes in Dublin-Core elements in EPUB 3

7 posts / 0 new
Last post

The specification
http://www.idpf.org/epub/30/spec/epub30-publications.html
seems to define attributes for Dublin-Core elements.
As far as I know, Dublin-Core itself defines only the elements,
but no further attributes. If I'm wrong, can you point me to the
Dublin-Core definitions of these attributes 'id' and 'dir'?

In '3.4 Package Document Definition' it is noted:
'All elements [XML] defined in this section are in the
http://www.idpf.org/2007/opf namespace [XMLNS] unless otherwise specified.'
Does this apply to the here defined attributes like 'id' and 'dir' as well?
If not, due to my understanding, without a prefix the meanings and interpretation of those attributes need to be defined by the definition of the element.
But this is in the Dublin-Core namespace, therefore Dublin-Core has to define
the meaning of such unprefixed attributes and not OPF/EPUB - can you point
to the Dublin-Core definition for such elements in their namespace?

The examples seem to implicate, that the attributes belong to the
element, because they have no prefix - are the examples wrong?

My assumption is currently, because EPUB defines them, those attributes
are in the namespace 'http://www.idpf.org/2007/opf' and need a prefix, if
used in Dublin-Core elements - as for example the XLink elements do in
SVG or attributes like epub:type
http://www.idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-conte...
do in XHTML content documents of EPUB.

At least for the id attribute - wouldn't it be a better solution for documents
with references between elements from different namespaces to use the
generic xml:id instead of an id in a specific namespace?

An element doesn't "own" attributes that don't have a prefix, and adding attributes doesn't require placing them in a namespace. Without a prefix, the attributes simply don't belong to any namespace.

Some vocabularies have tried to make it illegal to extend the vocabulary using unprefixed attributes (SVG 1.1 springs to mind), but that's often a bad thing to try and enforce. In the case of SVG 1.1., which is what EPUB allows, it means you can't use RDFa.

I believe EPUB 3 counts as "qualified Dublin Core", because of the refinement mechanism, but unless you know of a specific restriction against these attributes, there's nothing illegal that I can find in the implementation.

Well, XML says, those attributes without a prefix do not belong directly to a
namespace - I do not claim something different.
And the namespace it belongs to does not inherit for example from the
root element either, therefore in our case here OPF/EPUB does not define
the meaning either, nor does Dublin-Core obviously.

Iattributes are noted in an element without a prefix, the meaning is determined
by the element. This means effectively the specification of the element itself has to define such attributes - this is usually done - for example for SVG tiny 1.2 you can use RDFa with attributes defined in SVG, in SVG 1.1 you can use RDFa with attributes with a prefix indicating the XHTML namespace, SVG allows this in general and programs like Inkscape use this option for their applications to store additional information for the editor - only the DTD-validator does not manage to check this properly as for elements from other namespaces allowed in specific elements in SVG.

If Dublin-Core does not define the meaning of such attributes, they have no meaning without a prefix for their elements. To define a meaning for them in OPF/EPUB, one has to map the attributes to the OPF/EPUB namespace
somehow - and the only option to do this is to use a prefix.
The should be clarified and the examples should be fixed in the recommendations.

The main issue about the namespace thing is, that there is only one definition for one construct - this would be not the case, if everyone could define different meanings for unprefixed attributes in elements from other namespaces.

Using xml:id could have avoided this for the id attribute.
Well, for the dir attribute it is noted already in '3.4.4 The DCMES title Element':
'Inherent directionality specified using [Unicode] takes precedence over this
attribute.'
Because UTF-8 is used in EPUB and I think, most of this already implicates
some directionality - are there practical use cases, such an attribute really
applies? I think in (X)HTML and CSS the priorities for similar attributes or
properties are the other way around - what sounds more useful ...

If Dublin-Core does not define the meaning of such attributes, they have no meaning without a prefix for their elements

Where in the XML specifications is this stated? Or where in Dublin Core is it stated that any implementation of the elements cannot include unprefixed attributes? The only recommendations in the xml implementation guidelines is to use lower case names and prefix the elements. Nowhere does it say unprefixed attributes must be avoided and if you include any they are part of the DCMES definitions. Take a look at the notes at the bottom and you'll see discussions exhibiting unprefixed attributes.

As I said in my first post, unprefixed attributes are not necessarily "owned" by anyone; namespaces are just a convenience to avoid collisions. So long as the grammar is extensible, you can add attributes to this "global" namespace provided they don't collide with any existing attributes, which is what EPUB did. Moreover, Dublin Core doesn't provide a schema for its elements, so the normative reference is the Publications specification and schema. A chain going back to the DCMES definitions for these attributes isn't required, as it's an EPUB-specific implementation.

The id/xml:id ship has sailed, so a change now is unlikely. I fall into the trap of using xml:id in the package document as it does seem more natural, but having two id attributes in the same schema is fraught with problems.

As far as directionality goes, I believe the attribute only was added as a processing hint to avoid inspection, but I wasn't heavily involved in the global language support working group that proposed it.

There is always a risk of collision - maybe Dublin-Core once wants to define attributes or others follow the same idea as OPF/EPUB and define attributes with the same name - there is always a risk, if one tries to define something about a domain, other people are responsible for ;o)

I still think, authors have to use a prefix with the OPF-namespace to avoid collisions and conflicts and to get a document with a defined meaning...

The notes in the implementation guidelines indicate as well, that these
approaches related to examples with unprefixed attributes are not
recommended - but they do not explain explicitly, that it is not in general
discouraged to use unprefixed attributes for refinements, surely just because
it is obvious, that it will cause confusion and undefined statements ;o)
The recommended examples all contain prefixed attributes by the way ...

Maybe we're getting too far afield in namespace and ownership discussions... :)

Let me try another tack. It was a goal to get away from attributes on the elements, especially OPF-namespaced ones that were in EPUB 2, but there needed to be a way to reference the elements for refinements and provide a directionality hint.

Since the package document already uses an @id attribute, it's simply not possible to also use @xml:id just for these (and to change to xml:id would have broken compatibility with EPUB 2, which never would have happened just for purity in the metadata). The same is true of the @dir attribute, which is already in the specification at the package level.

But to your last post, this is an epub-specific implementation of the elements conforming to DCMES 1.1. No one but the IDPF can alter the package document schema, so there's no risk of future collisions if DC were to do another release as it wouldn't automatically be inherited, and no risk of misinterpretation in epub 3-compliant reading systems as they must use the Publications spec definitions. I haven't heard any desire to expand the attributes, either.

(And my point about the notes section is not whether they agree with the approaches, but that DC themselves recognize unprefixed attributes are in use and yet there is nothing suggesting the practice itself is illegal.)

Dublin Core isn't quite the same as a formal grammar, as I've never seen or heard that it circumscribes the implementation (e.g., you can use other attributes on an HTML meta tag that defines a DC property, but no one says that is illegal).

If it would have been intended to define the meaning and usage of those
elements in EPUB/OPF, surely elements in the own namespace should have
been used and not those from Dublin-Core.
I think it is ok to say, which elements at which place are ok and
have a meaning in an OPF-document and a refinement or restriction with own
methods is ok as well.
And obviously nothing is 'illegal' - any author can put everything in his
documents, but this does not necessarily mean, that this has a defined meaning for others. Dublin-Core defines elements with meanings and we can use this to share metainformation with a defined meaning.
But because the refinements and those few attributes are defined by OPF/EPUB, those belong into this namespace, to become a defined
meaning, if noted for a Dublin-Core element. It might not be wrong to note
arbitrary attributes in those elements, just they have no common meaning and
this is not changed, just because the root element comes from OPF - this applies for the 'id' in EPUB 2 as well, you are right, already this needs a prefix.
If I like, I can write my own specification with my ideas, what could be quite
useful for my use cases to redefine for example EPUB 3 (what could be
really interesting, because a lot of content I have currently does not fit into
EPUB 2 or 3 - like poetry or declarative animation and interactivity in SVG) - but does this mean, that this really changes the meaning of such documents within the EPUB/OPF domain? Either it results in another format or my 'improvements' have no meaning, because they are not defined
or mentioned or discouraged in the EPUB 3 recommendations. The same applies for unprefixed attributes for Dublin-Core elements - there is nothing, that prevents authors from doing this, but this does not mean, that this results
in a defined meaning for such additions. Obviously something like 'id' is quite
common, therefore the risk is low to create a lot of confusion - and the capabilities of usual programs to interprete in general XML documents with
mixed content are limited, therefore maybe you are right, such EPUB-viewers
do not have the quality to manage this and just extract information from documents not much caring about defined meanings, proper namespaces etc.
This can change, if a program appears, that has a stand-alone implementation for elements in the Dublin-Core namespace - this will not care about such
unprefixed attributes and has no reason to lookup for possible other meanings or dialects in other domains, that are maybe related.

Secondary menu