I'm now working on design and implementation of a XLink facility.
My approach is to provide the XLink facility as an engine.
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 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.
Best regards,
- Masatomo Goto
--- Masatomo Goto <gotou@flab.fujitsu.co.jp> Information Service Architecture lab. Fujitsu Laboratories Ltd. Tel: +81-78-934-8249 Fax: +81-78-934-3312