Xlink semantics

[Eve L. Maler]

This is a really good issue.  Obviously, the interactions among the
XLink-aware elements are underspecified!  I agree with Masatomo Goto's
interpretation of the various element configurations.  A few other comments
below...

At 01:20 AM 5/14/98 -0400, Masatomo Goto wrote:
>
>Hello,
>
>I'm now working on design and implementation of a XLink facility.
>My approach is to provide the XLink facility as an engine.

(This is wonderful!)

>At 20:45 98/05/13, Peter Murray-Rust wrote:
>> I have been hacking an application (the VHG DTD) using Xlink and I'd like
>> to check on some semantics. Since the spec has contentSpecs of ANY for all
>> three link-types the formal situation is that anything is permitted. Should
>> my software complain at the following examples (notation should be
>> obvious), or should it try to do something clever?
>
>In my Xlink engine, these examples are recognized as follows:
>
>> <extended>
>> 	<simple .../>
>> 	<simple .../>
>> </extended>
>> <!-- simple being used instead of locator -->
>
> - One extended link which has no or only inline resource 
>   (depends on inline attribute value)
> - Two simple links which are in the extended link content
>
>> <extended>
>> 	<locator .../>
>> 	<locator .../>
>> 	<simple .../>
>> </extended>
>> <!-- simple being used as well as locator -->
>
> - One extended link which has two or three(inline) resources.
> - One simple link which is in the extended link content
>
>> ...
>> <extended>
>> 	<locator .../>
>> </extended>
>> <!-- only one locator -->
>
> - One extended link which has one or two (inline) resources.
>
>> ...
>> <extended>
>> 	<extended>
>> 		<locator .../>
>> 		<locator .../>
>> 	</extended>
>> 	<extended>
>> 		<locator .../>
>> 		<locator .../>
>> 	</extended>
>> </extended>
>> <!-- hierarchical extended -->
>
> - One extended link which has no or only inline resources
> - two extended links which have two or three (inline) resources
>   in the parent extended link's content
>
>> ...
>> <foo>
>> 	<locator .../>
>> 	<locator .../>
>> </foo>
>> <!-- foo is the root element and has no xlink:form attribute -->
>> ...
>
> - no meaning. no processing.
>
>
>> The problem is that all of these throw no error in the parser as they are
>> probably impossible to constrain except in very spartan DTDs. I suspect
>> most are not productive, but some might be valuable on occasions I have or
>> haven't thought of.
>
>If the XLink processing facilities are separated from the application,
>It is possible to throw some errors from the "XLink processor".

This is how I envision linking support.  Each XML-related specification
suggests the creation of a "processor" for that level, with any other
"applications" overlaying it.  Of course, if you do encapsulate the
relevant XLink awareness into your DTD, you will get some validation "for
free."

>> This is an important occasion that there is a clear requirement for
>> applications to apply semantics to parts of one of the specs. We already
>> have to write an attribute processor and I'm interested in knowing how much
>> additional processing any conforming Xlink software is going to have to do.
>
>FYI, I will give a speach and demonstration about my XLink engine in 
>the HyTime at work session of SGML/XML Europe '98. 

I look forward to seeing it!

	Eve

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)