[sc34wg3] Subject Locators
Fri, 10 Jun 2005 21:29:58 +0200
On Jun 10, 2005, at 7:58 PM, Bernard Vatant wrote:
> Bingo, I think I understand,
> Is that what you meant? And it makes no difference if
> the resource type is "concept", "information resource" or
> In that case, we fully agree ...
Yes, there is no difference. Take 'homepage': is that a concept? or a
document? or is
it just the concept of that document?
But what is IMHO the underlying lesson to learn (at least I think it
is what I learned
a while ago) is that you cannot develop/design information systems
orthogonal to the
software architectural style that you use to build that system.
Example: XTM/TMDM make use of two different addressing contexts,
subject address and
subject indicator. This is not in itself a problem, but once you take
that to a system that
deliberately chooses (for architectural reasons) to have only one
addressing context, you
are bound to the system's 'design decisions'.
REST is pretty clear: if you enter a URI in your browser, you GET a
representation of the
resource that the URI identifies. The browser just invokes GET on the
Whatever XTM/TMDM defines, that cannot bechanged, because the REST
connector components are
only aware of this single addressing context. You cannot tel a
browser to use a given URI
either this way (as subject locator) or that way (as subject indicator).
Bottom line: a technology that builds upon another one (and XTM was
made for the Web IIRC)
does not get to redefine the terms.
Of course you can put whatever interpretations you want up in the
air, but then you are simply
not 'on the Web' anynmore. (Same reason why WS-* Web services have
nothing to do with
>> -----Message d'origine-----
>> De : email@example.com
>> [mailto:firstname.lastname@example.org]De la part de Bernard Vatant
>> Envoye : vendredi 10 juin 2005 19:37
>> A : email@example.com
>> Objet : RE: [sc34wg3] Subject Locators
>>> I guess Jan meant to write *you can never ever address a resource,
>>>> only a representation*
>>> No, no typo. With HTTP/URI you can never ever address a
>>> representation, only a resource.
>>>> ... otherwise I'm lost.
>> So I'm lost. I guess we have not the same understanding of either
>> "address", or
>> "representation" or "resource" (or all of those words) in this
>> context :((
>>> Have you read Fielding's dissertation? It is quite clear.
>> Only excerpts - I guess I should read it throughout - not tonight ...
>> I read in section 6.2.1. quoted by Patrick
>> "REST accomplishes this by defining a resource to be the semantics
>> of what the author
>> intends to identify, rather than the value corresponding to those
>> semantics at the time
>> the reference is created. It is then left to the author to ensure
>> that the identifier
>> chosen for a reference does indeed identify the intended semantics."
>> *the value corresponding to those semantics* is a
>> "representation", Y/N? and it is what
>> you "address", Y/N? So it's not the resource itself, Y/N? Where
>> is the flaw in my
>> But, beyond that, I guess you agree with the rest of my post?
>> (which is the most
>> sc34wg3 mailing list
> sc34wg3 mailing list
Jan Algermissen, Consultant & Programmer
Tugboat Consulting, 'Applying Web technology to enterprise IT'