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

Re: XLink resource confusion (long)

  • From: "Eve L. Maler" <eve.maler@e...>
  • To: David Jackson <jackson@d...>
  • Date: Mon, 07 May 2001 12:44:36 -0400

xlink local and remote resource
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


Purchase Stylus Studio Online Today!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.