playlist.location versus xml:base

[Sebastian Pipping-3]

I think xml:base was mentioned on this list some time ago on
but I cannot find the related thread any more...

I am wondering how XSPF's playlist.location element [1]
and the xml:base attribute [2] work together.
To make precise questions from that:

  - Does XSPF support xml:base ?

  - If so how does its usage differ from XSPF's
    playlist.location element ?

  - In case they conflict and appear together whic
    should be given priority ?

Does anybody know? Is this something we still have to decide?
Would be great if anybody could shed some light.

Thanks in advance,



Sebastian


[1] http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.5
[2] http://www.w3.org/TR/xmlbase/

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

It's xml:base itself that addresses this issue.  The relevant spec
section is http://xspf.org/xspf-v1.html#rfc.section.6.2 , which just
says that "Relative paths MUST be resolved according to the XML Base
specification or IETF RFC 2396."

We looked for outright conflicts between the spec and xml:base, and
also included this little pointer, and that's the whole of support.

>  - Does XSPF support xml:base ?

Yes.

>
>  - If so how does its usage differ from XSPF's
>    playlist.location element ?

If the location is absolute, xml:base isn't invoked.  If the location
is relative, the location is relative, and converting it to an
absolute URI follows the rules from RFC 2396.

There are a couple down sides of this situation.

In many cases resolving relative URIs is a big drag, so few apps
support it, and that leads to incompatibility between consumer apps.

Also, validating relataive URIs in XSPF (as in any xml:base format)
can't be done with certainty.  A relative URI which is valid in one
base URI can be in valid in another.  For example, URI syntax which is
legal in the HTTP scheme might be illegal in the DATA scheme, so the
validity of relative portions of the URI depends on how the XSPF file
is being served.

-Lucas

On Wed, Jul 16, 2008 at 12:12 PM, Sebastian Pipping
<webmaster@...> wrote:

> I think xml:base was mentioned on this list some time ago on
> but I cannot find the related thread any more...
>
> I am wondering how XSPF's playlist.location element [1]
> and the xml:base attribute [2] work together.
> To make precise questions from that:
>
>  - Does XSPF support xml:base ?
>
>  - If so how does its usage differ from XSPF's
>    playlist.location element ?
>
>  - In case they conflict and appear together whic
>    should be given priority ?
>
> Does anybody know? Is this something we still have to decide?
> Would be great if anybody could shed some light.
>
> Thanks in advance,
>
>
>
> Sebastian
>
>
> [1] http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.5
> [2] http://www.w3.org/TR/xmlbase/
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

I don't fully understand yet: In what cases do we need
playlist.location because xml:base cannot do alone?



Sebastian

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

On Thu, Jul 17, 2008 at 10:04 AM, Sebastian Pipping
<webmaster@...> wrote:
> I don't fully understand yet: In what cases do we need
> playlist.location because xml:base cannot do alone?

Ah, sorry, I finally got the question.  You are a very astute reader
of specs, man.

Until this moment I personally never thought about the implications
for relative URLs of playlist.location, and only ever thought about
xml:base as doing that job.

The question is the precedence of the xml:base attribute on a document
relative to the playlist.location element.  If one or the other is
set, the one which is set takes precedence.  But what if both are set?

Per the xspf spec, http://www.w3.org/TR/xmlbase/ is the governing spec
for relative paths.

Within the xml base documentation, xml:base is specifically mentioned
and playlist.location isn't.  So I would call xml:base
(http://www.ietf.org/rfc/rfc2396.txt 5.1.1) the higher precedence item
and playlist.location (http://www.ietf.org/rfc/rfc2396.txt 5.1.4) "the
context of the application," which gives it lower precedence.

How does that reasoning strike you?

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

Lucas Gonze wrote:
> How does that reasoning strike you?

Sounds good. I casted my current understanding into an algorithm.
Please let me know if this is what you meant.


===========================================================
if <playlist has xml:base attribute> then
   BASE = <xml:base>
else if <playlist has playist.location element> then
   if <playist.location is absolute URI> then
     BASE = <playist.location>
   else
     if <playlist referred to by encapsulating entity> then
       base_of_base = <URI of encapsulating entity>
     else if <playlist retrieved through absolute URI> then
       base_of_base = <retrieval URI>
     else
       base_of_base = <application/context defined base URI>
     fi
     BASE = resolve(<playlist.location>, base_of_base)
   fi
else if <playlist referred to by encapsulating entity> then
   BASE = <URI of encapsulating entity>
else if <playlist retrieved through absolute URI> then
   BASE = <retrieval URI>
else
   BASE = <application/context defined base URI>
fi
===========================================================


Sebastian

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

I'm thinking of the application-defined base as playlist.location,
meaning that XSPF is at the application layer.  The sequence would be:

if <playlist has xml:base attribute> then
   BASE = <xml:base>
else if <playlist enclosed in another document and other document has
a base per rfc2396> then
   BASE = base of encapsulating entity
else if <playlist retrieved through absolute URI> then
   BASE = dirname(<retrieval URI>)
else
   BASE = dirname(playlist.location)

YMMV...

On Thu, Jul 17, 2008 at 11:05 AM, Sebastian Pipping
<webmaster@...> wrote:

> Sounds good. I casted my current understanding into an algorithm.
> Please let me know if this is what you meant.
>
>
> ===========================================================
> if <playlist has xml:base attribute> then
>   BASE = <xml:base>
> else if <playlist has playist.location element> then
>   if <playist.location is absolute URI> then
>     BASE = <playist.location>
>   else
>     if <playlist referred to by encapsulating entity> then
>       base_of_base = <URI of encapsulating entity>
>     else if <playlist retrieved through absolute URI> then
>       base_of_base = <retrieval URI>
>     else
>       base_of_base = <application/context defined base URI>
>     fi
>     BASE = resolve(<playlist.location>, base_of_base)
>   fi
> else if <playlist referred to by encapsulating entity> then
>   BASE = <URI of encapsulating entity>
> else if <playlist retrieved through absolute URI> then
>   BASE = <retrieval URI>
> else
>   BASE = <application/context defined base URI>
> fi
> ===========================================================
>
>
> Sebastian
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

Lucas Gonze wrote:

> I'm thinking of the application-defined base as playlist.location,
> meaning that XSPF is at the application layer.  The sequence would be:
>
> if <playlist has xml:base attribute> then
>    BASE = <xml:base>
> else if <playlist enclosed in another document and other document has
> a base per rfc2396> then
>    BASE = base of encapsulating entity
> else if <playlist retrieved through absolute URI> then
>    BASE = dirname(<retrieval URI>)
> else
>    BASE = dirname(playlist.location)

Isn't playlist.location "embedded in the document's content"?
I thought the application/context defined base comes from outside
the file?



Sebastian


_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

Sebastian Pipping wrote:
> Isn't playlist.location "embedded in the document's content"?
> I thought the application/context defined base comes from outside
> the file?

My thinking is that none of the answers is a perfect match for
playlist.location, and the application context is the closest match
for it.  "embedded in the document's content" means, I suspect but am
not sure, using xml:base.

One thing we could do is ask the authors of xml base for advice.

-L


On Sat, Jul 19, 2008 at 4:18 AM, Sebastian Pipping
<webmaster@...> wrote:

> Lucas Gonze wrote:
>> I'm thinking of the application-defined base as playlist.location,
>> meaning that XSPF is at the application layer.  The sequence would be:
>>
>> if <playlist has xml:base attribute> then
>>    BASE = <xml:base>
>> else if <playlist enclosed in another document and other document has
>> a base per rfc2396> then
>>    BASE = base of encapsulating entity
>> else if <playlist retrieved through absolute URI> then
>>    BASE = dirname(<retrieval URI>)
>> else
>>    BASE = dirname(playlist.location)
>
> Isn't playlist.location "embedded in the document's content"?
> I thought the application/context defined base comes from outside
> the file?
>
>
>
> Sebastian
>
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

Hello,

Lucas Gonze schrieb:
> My thinking is that none of the answers is a perfect match for
> playlist.location, and the application context is the closest match
> for it.  "embedded in the document's content" means, I suspect but am
> not sure, using xml:base.
>  
I looks for me that the playlist.location same as xml:base attributes
are "embedded in the document's content". XML Base definitley is (as it
is said at "4.1 Relation to RFC 3986").
The matter is that playlist.location is "embedded in the document's
content" but holds the URI to "the encapsulating entity".
So we can't decide from this few rules wich to prefer.
I think we have to define wich one we should use to resolve relative
URIs. For me I favor xml:base because of flexibility and the point that
XML Base is a standard.
On the other hand playlist.location doesn't keep the URI to "the
encapsulating entity". If a playlist file is moved it doesn't represent
the location to itself anymore (but of course to the origin).
> One thing we could do is ask the authors of xml base for advice.
>  
This would be a good thing. Perhaps it's all rubbish what I wrote above :)

Clemens 'M@d Man' Terasa

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

Assuming I understand your point correctly, the situation is that the
XML Base spec specifically disallows playlist.location in rule #1,
saying: "This document specifies the details of rule #1 for embedding
base URI information in the specific case of XML documents."

That is, the XSPF spec promises to be compliant with the XML Base
spec, and the XML Base spec reserves rule #1 for itself.

> On the other hand playlist.location doesn't keep the URI to "the
> encapsulating entity". If a playlist file is moved it doesn't represent
> the location to itself anymore (but of course to the origin).

Ok, let's pull out to our application goals.  What's best for
portability and interoperability, and hence shareability?

Both xml:base and playlist.location are absolute references which
don't travel when a copy is made, so there's no difference in what
happens once the playlist is moved.  xml:base is more broadly
understood and implemented, and is a formal standard.  It seems wise
to defer to it.  On the other hand, this defies the plain sense that
the playlist.location element is useful in this context.

The Atom protocol has a "self" link which presents some of the same
issues.  Maybe there's a precedent there.

-Lucas


On Mon, Jul 21, 2008 at 3:59 PM, M@d Man <BLmadman@...> wrote:

> I looks for me that the playlist.location same as xml:base attributes
> are "embedded in the document's content". XML Base definitley is (as it
> is said at "4.1 Relation to RFC 3986").
> The matter is that playlist.location is "embedded in the document's
> content" but holds the URI to "the encapsulating entity".
> So we can't decide from this few rules wich to prefer.
> I think we have to define wich one we should use to resolve relative
> URIs. For me I favor xml:base because of flexibility and the point that
> XML Base is a standard.
> On the other hand playlist.location doesn't keep the URI to "the
> encapsulating entity". If a playlist file is moved it doesn't represent
> the location to itself anymore (but of course to the origin).
>> One thing we could do is ask the authors of xml base for advice.
>>
> This would be a good thing. Perhaps it's all rubbish what I wrote above :)
>
> Clemens 'M@d Man' Terasa
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

On Mon, Jul 21, 2008 at 5:06 PM, Lucas Gonze <lucas.gonze@...> wrote:
> The Atom protocol has a "self" link which presents some of the same
> issues.  Maybe there's a precedent there.

RFC 4287's invocation of xml:base is:
"
Any element defined by this specification MAY have an xml:base
   attribute [W3C.REC-xmlbase-20010627].  When xml:base is used in an
   Atom Document, it serves the function described in section 5.1.1 of
   [RFC3986], establishing the base URI (or IRI) for resolving any
   relative references found within the effective scope of the xml:base
   attribute.
"

It defines the self construct as:
"
This is the preferred URI for
      retrieving Atom Feed Documents representing this Atom feed.
"

That is, if xml:base exists in the document it definitely trumps, and
the use of the self construct to establish a base URI isn't addressed.

My feeling is that rule #4 is the place for fudge factors like
playlist.location.

-Lucas

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

Lucas Gonze wrote:
> This is the preferred URI for
>       retrieving Atom Feed Documents representing this Atom feed.
>
> That is, if xml:base exists in the document it definitely trumps, and
> the use of the self construct to establish a base URI isn't addressed.

Do you mean playlist.location should be used as the URI to retrieve
an updated version of this playlist and that it should not be taken
into account for URI reference at all? That would also answer the
question of handling a relative URI in playlist.location.


> My feeling is that rule #4 is the place for fudge factors like
> playlist.location.

Sorry, I fail to find any "base" to resolve this reference - what rule #4?



Sebastian

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

I have cast my current understanding into a new
entry for the 'XSPF v1 Notes and Errata' article [1]
in the Xiph Wiki. If this is all wrong or incomplete,
now would be a great time to fix or extend it ;-)



Sebastian


[1] http://wiki.xiph.org/index.php/XSPF_v1_Notes_and_Errata

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze]

I like this a lot.  It's clear and precise.

On Tue, Jul 29, 2008 at 12:00 PM, Sebastian Pipping
<webmaster@...> wrote:

> I have cast my current understanding into a new
> entry for the 'XSPF v1 Notes and Errata' article [1]
> in the Xiph Wiki. If this is all wrong or incomplete,
> now would be a great time to fix or extend it ;-)
>
>
>
> Sebastian
>
>
> [1] http://wiki.xiph.org/index.php/XSPF_v1_Notes_and_Errata
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist