[Matroska-devel] EBML Namespaces
steve.lhomme at free.fr
Sun Apr 9 16:19:07 CEST 2006
HAESSIG Jean-Christophe wrote:
> I would like to know if there are any plans to include some namespacing
> feature into EBML.
> I think namespaces are an important feature to enable compositing of
> EBML documents and
> transparent extension of existing formats.
Well, extending an EBML document with more tags has been discussed in
the past. The idea was to include a DTD in the header. But using DTDs
mean we can use external ones too (as in HTML/XML). But there's always
the issue of ID collision.
> Just in case, if nobody ever seriously thought about it, please consider
> the following
> proposal :
> my idea is to replace the high order bits (not the ones coding for the
> ID length) of
> the Class-IDs with a namespace ID. First of all, a few new level 1+
> Class-IDs are
> defined : 4288, an integer element that defines how many bits are used
> for namespacing.
> 4289 is the namespace declaration element. It has two sub-elements : 81
> is an integer
> representing the namespace ID, 82 is a string containing the namespace
> key, which can
> be a URL, as in traditional XML namespaces, or a public key fingerprint.
This is similar to the DTD system. Except you're changing the ID
parsing. I think Class 3, 4 (and even Class 2) level offers enough IDs
to avoid collision for formats in the same field of work (multimedia,
banking, tagging, etc).
Now the idea of a namespace would mean that the same ID would be used by
2 formats but with a different meaning. But given you set the different
namespace in each ID, de facto they have a different ID. So I don't
really see how it solves the problem of collision.
> When a Class-ID has high-order set bits that would conflict with the
> namespace ID,
> that Class-ID is simply represented as a larger class (it would be
> coherent with the
> EBML RFC section 2.2, which states that Class-IDs are always encoded in
> their shortest
> Form, therefore no ID clashes can happen)
> The namespace ID is always 0 for EBML elements, so for files using up to
> 7 additional
> namespaces, the header elements wouldn't change at all. Another
> advantage of my
> approach is that the lowest level of EBML parsers (which do not
> interpret Class-IDs)
> would not be confused by the files using namespaces.
Yes, but you still need to map, at the lowest level, the namespaces for
each upper level reader.
> I welcome any comments and would be pleased to answer if further detail
> is required
Sure. Maybe I didn't get your solution right. But I'm glad someone is
trying to extend EBML. The main missing feature for the moment is the
inability at the lower level to know if an element is EBMLMaster or not.
So it's impossible to display a map of an EBML document without knowing
More information about the Matroska-devel