Re: Xlink semantics
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format