[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XLink resource confusion (long)

• From: jackson <jackson@d...>
• To: "Christopher R. Maden" <crism@m...>, xml-dev@l...
• Date: Sun, 06 May 2001 17:34:20 +1000

Chris

> Well, you demonstrate several extended links which are not equivalent, but
> there is an equivalent link.
>
> >Consider this example:

[delete]

Thanks for this Chris. This seems to do the job.

The solution is a solution, despite being rather convoluted.
But that's just the nature of things XLink i suppose.

Eve was pointing me in this direction, but i was hoping for
something a little more straightforward. I guess i'll just have
to accept the necessity of this approach.

Extended third-party links are starting to look good.

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.)

In this case it might look near enough not to matter, but the simple
link has a name ('studentlink') which is part of the resource. It is
not part of the local resource in the extended version.

Also, if the 'studentlink' has non-XLink attributes, these would also
be part of the local resource of the simple link, but not the extended
link.

Further, 'studentlink' is simpler than the example i gave in that it
only has one child node (the text). The real problem is in dealing
with more than one child node - which to be equivalent to the
simple link case must be treated as one resource.

Your solution does not have any of these problems.

> 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.

'Simple' and 'extended' Xlink elements would have to be excluded from
this exclusion since they can be legitimate parts of a resource as resource.
That is, a link (a different one) can be a legitimate part of a resource.

David Jackson

• Follow-Ups:
  • Re: XLink resource confusion (long)
    • From: "Eve L. Maler" <eve.maler@e...>

• References:
  • Re: XLink resource confusion (long)
    • From: "Christopher R. Maden" <crism@m...>

• Prev by Date: Re: XLink resource confusion (long)
• Next by Date: Re: Dumb questions about PUBLIC IDs
• Previous by thread: Re: XLink resource confusion (long)
• Next by thread: Re: XLink resource confusion (long)
• Index(es):
  • Date
  • Thread