3.1.2 Link to URL of the XSI document within the Service website
43 views
Skip to first unread message
Andy Buckingham (RadioDNS)
Apr 27, 2012, 7:23:26 AM4/27/12
to radioepg-...@googlegroups.com
I would like to propose an additional point to section 3.1.2 regarding
the link of an XSI document in an HTML document related to a service.
This in turn proposes a tweak to the XSI specification which is full
backwards compatible.
In the example given in the spec, it is explained that the home page
of a radio station website could contain a snippet such as:
<html>
<head>
<link rel="radioepg" href="http://epg.musicradio.com/radiodns/epg/XSI.xml">
</head>
<body>
<h1>Station FM</h1>
</html>
One application of this would be to allow a client to offer the user
the option of adding a service to the client by website URL. The
explanation goes on to point out that if a service provider hosts an
XSI document detailing a number of services (perhaps the full
portfolio of services owned by that provider) then it could add the
same header to each radio station home page.
It is an existing standard for XML document URLs that a URL fragment
may be used to indicate a specific entity within the addressed
document. To this extent, we could extend the inclusion of XSI URL to
also hint which specific service contained within is related to the
HTML document being consumed:
<html>
<head>
<link rel="radioepg"
href="http://epg.musicradio.com/radiodns/epg/XSI.xml#station-fm">
</head>
<body>
<h1>Station FM</h1>
</html>
This tells the XSI parser that, of all the services contained in the
XSI, the service element with an xml:id attribute of "station-fm" is a
representation of the HTML document that linked to this XSI, e.g.:
<serviceInformation ...>
<services>
<service id="station-fm">
<serviceID cost="70"...
The eagle-eyed readers amongst you will spot the inclusion of a new
attribute on the <service> element. This is the xml:id attribute from
the XML specification, which also defines how a fragment in a URL
should match the element containing the same ID.
In summary:
* I propose the addition of the ability to add an additional fragment
component to the URL in the HTML link tag for XSI documents to refer
to a specific service within the document.
* I also propose the addition of an optional id attribute to the XSI
document on service elements.
I believe neither of these changes will break backwards compatibility with v1.0
Thanks,
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
the link of an XSI document in an HTML document related to a service.
This in turn proposes a tweak to the XSI specification which is full
backwards compatible.
In the example given in the spec, it is explained that the home page
of a radio station website could contain a snippet such as:
<html>
<head>
<link rel="radioepg" href="http://epg.musicradio.com/radiodns/epg/XSI.xml">
</head>
<body>
<h1>Station FM</h1>
</html>
One application of this would be to allow a client to offer the user
the option of adding a service to the client by website URL. The
explanation goes on to point out that if a service provider hosts an
XSI document detailing a number of services (perhaps the full
portfolio of services owned by that provider) then it could add the
same header to each radio station home page.
It is an existing standard for XML document URLs that a URL fragment
may be used to indicate a specific entity within the addressed
document. To this extent, we could extend the inclusion of XSI URL to
also hint which specific service contained within is related to the
HTML document being consumed:
<html>
<head>
<link rel="radioepg"
href="http://epg.musicradio.com/radiodns/epg/XSI.xml#station-fm">
</head>
<body>
<h1>Station FM</h1>
</html>
This tells the XSI parser that, of all the services contained in the
XSI, the service element with an xml:id attribute of "station-fm" is a
representation of the HTML document that linked to this XSI, e.g.:
<serviceInformation ...>
<services>
<service id="station-fm">
<serviceID cost="70"...
The eagle-eyed readers amongst you will spot the inclusion of a new
attribute on the <service> element. This is the xml:id attribute from
the XML specification, which also defines how a fragment in a URL
should match the element containing the same ID.
In summary:
* I propose the addition of the ability to add an additional fragment
component to the URL in the HTML link tag for XSI documents to refer
to a specific service within the document.
* I also propose the addition of an optional id attribute to the XSI
document on service elements.
I believe neither of these changes will break backwards compatibility with v1.0
Thanks,
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
Andy Buckingham (RadioDNS)
May 15, 2012, 3:54:32 PM5/15/12
to radioepg-...@googlegroups.com
...welcome back to those who join us from the other thread on the list
regarding the use of "id" attributes in XML.
I'd like to extend this suggestion to explicitly define the id
attribute as being in the xml namespace. This implies special meaning
to the attribute that it should be unique within the document,
improving our use of it with an anchor in the URL to pinpoint a
specific service:
<serviceInformation ...>
<services>
<service xml:id="station-fm">
<serviceID cost="70"...
A
On 27 April 2012 12:23, Andy Buckingham (RadioDNS)
regarding the use of "id" attributes in XML.
I'd like to extend this suggestion to explicitly define the id
attribute as being in the xml namespace. This implies special meaning
to the attribute that it should be unique within the document,
improving our use of it with an anchor in the URL to pinpoint a
specific service:
<serviceInformation ...>
<services>
<service xml:id="station-fm">
<serviceID cost="70"...
A
On 27 April 2012 12:23, Andy Buckingham (RadioDNS)
Reply all
Reply to author
Forward
0 new messages