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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Xlink semantics

[ Lists Home | Date Index | Thread Index ]
  • From: Masatomo Goto <gotou@flab.fujitsu.co.jp>
  • To: Peter Murray-Rust <peter@ursus.demon.co.uk>, xml-dev@ic.ac.uk
  • Date: Thu, 14 May 1998 14:20:07 +0900


Hello,

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

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


  • References:



 

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

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