You might want to check the current WD (just released 1/20/00), which eliminates the XLinks-as-elements syntax (such as the xlink:extended and xlink:locator in your example). That aside, note that while you can assign a role attribute to the parent extended-type element, THAT role has nothing to do with the from/to attributes on arc-type elements. The latter must match up (according to [3.1.4]) with the role attribute on a LOCATOR-type element in the same extended link definition. (This should probably be amended to match the roles of either locator-type OR resource-type elements, per a couple of messages posted to www-xml-linking-comments earlier this week.) (And your P.S., wanting to put a role attribute on arcs -- you CAN put a role attribute on arc-type elements.) I don't know if the example you posted -- the academic course catalog -- is the specific purpose of your application or just an example. As presented, yes, it appears to present a problem. Actually it looks to me like the application design would need work in this case, eliminating what seem to be XLink problems. For example, the parent of the extended-type element would presumably be course info. Therefore, the only courses listed in the extended link group would be prerequisites for THAT course. Or (if all the course-info records were in the same document) you could have a "prereqs" attribute of type IDREFS on the main course element, eliminating all XLinks (at least to external documents). Just a suggestion!Received on Friday, 21 January 2000 09:30:50 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:40 GMT