[
Lists Home |
Date Index |
Thread Index
]
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>
>
>
|
