[Matroska-devel] Re: EBML Namespaces

Atamido paul at msn.com
Thu Apr 27 17:56:27 CEST 2006


This all seems a little on the complex side.  Why not just define an 
element that indicates a change of name space for all formats? 
Something  without much chance of random collision like:
[12][34][56][78]

If you want to be able to indicate *which* name space you are changing 
to, then include a child element that includes the format's DocType:
[13][87][65][43]

Either have that as the first element, with other elements from the new 
name space following later, or put all of the elements from the new name 
space in their own element like:
[14][87][12][87]

So, format XYZ that wants to contain a Matroska file would contain this:
[12][34][56][78] (size)
	[13][87][65][43] (size) {matroska}
	[14][87][12][87] (size)
		[18][53][80][67] (size)


This seems pretty strait forward and backwards compatible to me.  Am I 
missing something?


Atamido

HAESSIG Jean-Christophe wrote:
> Hello,
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> 
>  
> 
> I welcome any comments and would be pleased to answer if further detail 
> is required
> 
> JC Haessig.
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel




More information about the Matroska-devel mailing list