Content-oriented Navigation II: URI
I'm one of the SW mailing list readers tired of never ending URI discussions. Definitely I do not want to contribute to these discussions. But I need to describe how it is going to be solved in Vodyanoi and also to reference this description from the other posts building on top of this feature.
So just a few insights...
...and that's it. No flamewar please :-)
So just a few insights...
- URI = URN u URL.
- While URN identifies resource, URL describes (temporal) location of its representations.
- Do not mix URN semantics with URLs.
- URN can be (temporarily) resolved to multiple URLs - per (REST) representation.
- Once defined, URN never perish and never should be reused for another entity. In case of resource is no longer interesting or it is obsolete, you may mark it as "discarded".
- You should define unique URNs - you may ensure that it will be unambiquous using pattern like:
urn:[your domain]:[project]:[{your ID}]:[resource]
for example:
urn:com:e-mental:mindraider:dvorka:refactoring-review
or
urn:com:e-mental:dvorka:family
- Avoid usage of URLs in the meaning of URNs i.e. SW identification of the resource should not start with a specific scheme like
http://
- use rather some URN like shown above. Only thus you will avoid confusion URNs with URLs. In other wordsurn:com:e-mental:mindraider:dvorka:refactoring-review
resource you may get using various protocols (http:// ftp://) in various representations ((X)HTML, TXT, etc.).
- Although human readable URNs should be treaten as opaque! I.e. you should not for example parse URN in order to get name of the resource author or domain.
- See also Content based navigation post.
...and that's it. No flamewar please :-)
Labels: mindraider
0 Comments:
Post a Comment
<< Home