OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XLink resource confusion (long)



At 05:34 PM 5/6/01 +1000, jackson wrote:
>...
>I think your example is better than the example in the draft spec
>(http://www.w3.org/TR/xlink/#simple-links):
>
>"A simple link could be represented by an extended link in
>approximately the following way:
>
><studentlink xlink:type="extended">
>   <resource
>     xlink:type="resource"
>     xlink:label="local">Pat Jones</resource>
>   <locator
>     xlink:type="locator"
>     xlink:href="..."
>     xlink:label="remote"
>     xlink:role="..."
>     xlink:title="..." />
>
>   <go
>     xlink:type="arc"
>     xlink:from="local"
>     xlink:to="remote"
>     xlink:arcrole="..."
>     xlink:show="..."
>     xlink:actuate="..." />
></studentlink>
>"
>
>Then:
>
>"The simple equivalent of the above extended link would be
>as follows:
>
><studentlink xlink:href="...">Pat Jones</studentlink>
>"
>
>I don't think these are equivalent. The simple link is itself its own
>local resource. The extended link _is not_ the local resource,
>but _has_ a local resource. (This is what i was saying in my first
>e-mail.)

You're right, they're not exactly equivalent because of this, but they 
function just about the same.  Chris's example gives an approximately 
"participant-equivalent" view, whereas the example in the spec gives more 
of an "arc-direction-equivalent" view (from local to remote).

> > This does not have local resources, and includes two loc elements and one
> > arc element within the beginning resource that weren't there in the other
> > example, but is otherwise equivalent.
>
>This is actually quite significant. These 'loc' and 'arc' elements are
>in fact content of the 'section' element in your example, so should
>be considered as part of that remote resource. Which means that it
>is not quite equivalent to the simple link version. (I know this is
>nit-picking a little, but it is perhaps necessary to see where it takes
>us.)
>
>Of course we can agree to consider the 'loc' and 'arc' elements as
>not part of the remote resource which is the 'section' element. That
>is, if we agree that XLink-defined elements ('loc' and 'arc' in this case)
>are expressly excluded from the remote resource 'section'.
>
>However, i don't know if the draft spec as it stands gives us licence
>to do that. Does the spec say anything about this? It's perhaps implied.

No, it doesn't give this license.  The resource is the content pointed to, 
and with the bare-name XPointer in Chris's example, this nets out to being 
a whole element node.  FWIW, I think it would probably be too invasive to 
tell applications not to count certain subelements as being part of a resource.

         Eve
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com