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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] XLink question re: arc duplication

[ Lists Home | Date Index | Thread Index ]

Don, 

I was using that particular example only because I didn't want to have
to explain the situation where it is an issue for me. I was trying to
reuse an existing example (from the rec in this case). I can think of
semantics where this would be meaningful, although they might be
contrived (but semantics often are contrived specifically for the
context in which they are used). Perhaps this is used by a museum for
managing school groups where they want to be able to know which parents
belong to which students and which teachers manage which students. Like
I said, contrived. 

My in my real situation, I have a description of an HTML page which
consist of a locator that is the layout engine (probably an XSL
transform but that doesn't matter) and a bunch of data that is mapped to
it in different roles. We use navigation, main content, header and
footer content, related links, marketing (callouts) and marketing
(banners) as roles on our pages. 

Now lets say that we have a schema that represents a product. Because
these are all financial products (our clients are Canadian credit
unions) it includes text descriptions, rate information and current
marketing campaigns/info. It is completely reasonable that I may want to
use product information as both main content and marketing callout. My
only recourse is to duplicate the locator for that one resource but that
doesn't make sense to me since all I want to do is use a different arc. 

I suppose that I could move those semantics to the locator but it seems
to me to be the wrong place. And just because I can swap the semantics
between the locator and the arc, doesn't mean all instances can (and
still maintain their meaning). 

Take for instance another example of a sitemap where I have more
relationships than just direct children. Suppose I'm using the link
types from HTML as my semantics to express this (you know prev, next,
chapter, etc http://www.w3.org/TR/html4/types.html#type-links). It would
make sense that on page 2 of a chapter, the link to both the previous
page and the start of the chapter would be the same resource. Using RDF
notion of a property (as http://www.w3.org/TR/xlink/#xlink-arcs
suggests) we can reasonably say:

chapter1_page2 HAS previous_page chapter1_page1
chapter1_page2 HAS chapter_start chapter1_page1

Or as an extended xlink with a lot of extra (but necessary) stuff
assumed (the href might not be exactly legal but you should know what I
mean):

<page id='chapter1_page2'>
	<link xlink:href="#chapter1_page1" xlink:label="link1"
xlink:role="http://cucbc.com/schema/sitemap/navigationnode"; />
	<rel xlink:to='link1'
xlink:arcrole="http://www.w3.org/TR/html4/types/link/prev"; />
	<rel xlink:to='link1'
xlink:arcrole="http://www.w3.org/TR/html4/types/link/chapter"; />
...
</page>
<page id="chapter1_page1"> ...</page>

This seems to me to be a perfectly reasonable and useful xlink (assuming
you really wanted to normalize your site map like this) its unfortunate
that its illegal. 

I hope this makes my case more clear. 

Adam

> -----Original Message-----
> From: Don Smith [mailto:donalds@isogen.com] 
> Sent: October 9, 2002 6:51 AM
> To: list@adamvandenhoven.com; XML Dev
> Subject: RE: [xml-dev] XLink question re: arc duplication
> 
> 
> Adam:
> 
> While I think you have produced an example that does indeed 
> indicate two different semantics between parent1 and child1, 
> I'm going to guess that the reasoning behind the constraint 
> goes something like this:
> 
> In the context of single link, it doesn't make sense to have 
> more than one traversal between the same two resources (what 
> would a UI do with them?). If you have occasion to have 
> different traversal semantics between the same two resources, 
> you simply create two links. Perhaps this is what you are 
> trying to avoid, though.
> 
> Keeping with your example, if you added role semantics to the 
> whole link and each of the resources in the link, I wonder if 
> it would make clear why having two links makes sense. For 
> example, assume that you described the role of the entire 
> link as a "parent-child" link. The role of each resource 
> would then be either "parent" or "child"; the arcroles would 
> be either "mother", "father", "daughter," or "son" as your 
> example indicates. Whence comes the arcrole "teacher" in such 
> a link? It seems out of place, even if in other contexts 
> (i.e., other links) it certainly makes sense.
> 
> Don
> ISOGEN International
> 
> 
> 
> > -----Original Message-----
> > From: Adam van den Hoven [mailto:list@adamvandenhoven.com]
> > Sent: Tuesday, October 08, 2002 7:31 PM
> > To: XML Dev
> > Subject: [xml-dev] XLink question re: arc duplication
> >
> >
> > Can someone explain to me the reasoning behind 
> > http://www.w3.org/TR/xlink/#cn-arc-duplicates?
> >
> > It seems to me that it would be more useful to make the constraint 
> > that to, from and arcrole are unique, not just from and to. I'm not 
> > sure why two resources could not be related in two 
> different ways. For 
> > example, consider the following which might represent a class 
> > (modified from the
> > rec):
> >
> > <extendedlink xlink:type="extended">
> >   <loc xlink:type="locator" xlink:href="..." xlink:label="parent1" 
> > xlink:title="p1" />
> >   <loc xlink:type="locator" xlink:href="..." xlink:label="parent2" 
> > xlink:title="p2" />
> >   <loc xlink:type="locator" xlink:href="..." xlink:label="parent3" 
> > xlink:title="p3" />
> >   <loc xlink:type="locator" xlink:href="..." xlink:label="child1" 
> > xlink:title="c1" />
> >   <loc xlink:type="locator" xlink:href="..." xlink:label="child2" 
> > xlink:title="c2" />
> >   <loc xlink:type="locator" xlink:href="..." xlink:label="child3" 
> > xlink:title="c3" />
> >   <go xlink:type="arc" xlink:from="parent1" xlink:to="child1" 
> > xlink:arcrole=".../teacher"/>
> >   <go xlink:type="arc" xlink:from="parent1" xlink:to="child2" 
> > xlink:arcrole=".../teacher"/>
> >   <go xlink:type="arc" xlink:from="parent1" xlink:to="child3" 
> > xlink:arcrole=".../teacher"/>
> >   <go xlink:type="arc" xlink:from="parent1" xlink:to="child1" 
> > xlink:arcrole=".../mother"/>
> >   <go xlink:type="arc" xlink:from="parent2" xlink:to="child2" 
> > xlink:arcrole=".../father"/>
> >   <go xlink:type="arc" xlink:from="parent3" xlink:to="child3" 
> > xlink:arcrole=".../mother"/> </extendedlink>
> >
> > Now this fails the arc constraint but I would argue that they are 
> > semantically unique. I've come across one situation where 
> this sort of 
> > thing would be very useful (but I'm loath to go it alone... Someone 
> > once told me its better to be standard than right). Now it 
> seems that 
> > I'll have to go through the awkward step of duplicating 
> locators so I 
> > can follow the rec (or I have to redo my semantics).
> >
> > I know that many people don't particularly like XLink, but I think 
> > it's a worth while tool for doing these sorts of things.
> >
> > H. Adam van den Hoven
> > Web Developer
> > Credit Union Central of BC
> >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an 
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
> >
> >
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS