3.3.6 memberOf

[Andy Buckingham (RadioDNS)]

In RadioEPG 1.0, Section 3.3.6 regarding the "memberOf" element of a
"service" element.

It is stated that the only attribute of this element by "id",
depicting the ID of the group that the service belongs to. However,
the matching group is then defined as having an "id" attribute to
match.

It is my understanding that XML specifies the "id" attribute as having
special meaning and that it should be unique to the entire document,
to allow the referencing of a specific element in the DOM by ID alone
(as implemented in most DOM manipulation libraries).

For safety, I propose changing this to "groupId" or something
similarly descriptive.

For backwards compatibility until a major revision, it may be worth
retaining the original "id" attribute too and marking it as
deprecated.


Andy.

--
Andy Buckingham
RadioTAG Application Team Lead
RadioDNS Project and Global Radio (UK)

t: +44 (0)117 900 5357
e: andy.bu...@radiodns.org
w: http://radiodns.org/

Follow the RadioDNS Project via Twitter: @radiodns

[Ben Poor]

Hi Andy,

Good observation, but not sure I agree its of the need to make changes.

The existing DAB EPG XML specification upon which RadioEPG is built does not respect the intentions of the id field in several areas:

* serviceID/bearer.id can theoretically contain identical bearers in a SI, and certainly a PI can contain the same bearer.id field across multiple programmes.

* memberOf.id on a programme in a PI may not be unique in the same document, with multiple programmes belonging to the same group

I appreciate this may be desirable when producing a new XML specification, but we're inheriting here so have to follow the path that DAB EPG took, including removing any special meaning to the 'id' attribute on elements.

Ben

[Mo McRoberts]

Hi all,

From memory, it's the specific xml:id which has specific meaning, where a bare 'id' is only special in HTML documents.

If there's a reference to a spec which contradicts me here, or parsers in widespread use which don't behave this way, I'd be very interested to know.

M.

[Andy Buckingham (RadioDNS)]

http://uk3.php.net/manual/en/domdocument.getelementbyid.php

Granted, being PHP (<insert typical PHP dig here>) it's probably
geared up for HTML DOM manipulation. The Java SE DOM Document object
has the same method though:

http://docs.oracle.com/javase/1.4.2/docs/api/org/w3c/dom/Document.html#getElementById(java.lang.String)

As I'd be unable to use these, I'd have to iterate element and observe
the attribute.

[Mo McRoberts]

On Tue, May 15, 2012 at 2:28 PM, Andy Buckingham (RadioDNS)
<andy.bu...@radiodns.org> wrote:
> http://uk3.php.net/manual/en/domdocument.getelementbyid.php
>
> Granted, being PHP (<insert typical PHP dig here>) it's probably
> geared up for HTML DOM manipulation.

Hmm, not by default:

“For this function to work, you will need either to set some ID
attributes with DOMElement::setIdAttribute or a DTD which defines an
attribute to be of type ID. In the later case, you will need to
validate your document with DOMDocument::validate or
DOMDocument::$validateOnParse before using this function.” — that is,
you have to tell it that the 'id' attribute is actually *the* ID
attribute.

> The Java SE DOM Document object
> has the same method though:
>
> http://docs.oracle.com/javase/1.4.2/docs/api/org/w3c/dom/Document.html#getElementById(java.lang.String)

Similarly:

“The DOM implementation must have information that says which
attributes are of type ID. Attributes with the name "ID" are not of
type ID unless so defined. Implementations that do not know whether
attributes are of type ID or not are expected to return null.”

M.

--
Mo McRoberts
mo.mcr...@nexgenta.com

[Andy Buckingham (RadioDNS)]

Thanks for clearing this up Mo.

It would appear therefore we've not broken any conventions in the
current RadioEPG schema and so my point is void.

In a seamless segue-way, this provides an interesting bit of
additional detail for my other open thread...