RE: [xtm-wg] XTM Conformance and Error Handling

["Wrightson, Ann" <Ann.Wrightson@sweetandmaxwell.co.uk>]

Seems to me it should be possible to usefully "mend" broken maps, just like
the browser issues mentioned below were often in practice handled by making
heuristic assumptions about what kind of correct HTML structure the buggy
one was intending to be. 
There isn't a full/perfect solution, of course, - but a published agreed
strategy for conforming apps to use to fix buggy topic maps could be
practically useful - and the patches must be clearly identifiable in the
patched topicmap, and conforming processors must be able to flag errors. 
However, let's leave this till after this week-end!!

Ann W.

> -----Original Message-----
> From: Murray Altheim [mailto:murray.altheim@eng.sun.com]
> Sent: 09 October 2000 20:44
> To: xtm-wg@egroups.com
> Subject: [xtm-wg] XTM Conformance and Error Handling
> 
> 
> [Was: Re: [xtm-wg] Syntax is a bitch :-( ]
> 
> Michel Biezunski wrote:
> > 
> > [Eliot Kimber:]
> > 
> >  For example, with XPath, it's almsot as easy to
> > > address by unique topic name as it is to address by ID value.
> > 
> > Except that this solution will not work if there is the 
> slightest change
> > in your topic map document. Therefore this is only  
> advisable if the topic
> > map
> > is never going to change.
> > 
> > (The ID strategy does not completely protect from the same 
> problem, but it's
> > slightly sounder.)
> 
> This reminds me of the Netscape error strategy. Had Netscape 
> (or Mosaic
> prior to it) flagged errors in HTML documents the Web might 
> have become a
> cleaner place, albeit more difficult for authors. If topic maps are
> edited with validating editors, or XTM processors typically validate
> on the fly, then conflicting IDs immediately become apparent. But if 
> topic maps prove as messy as typical HTML documents (and I 
> have no doubt
> they will be, sadly) then there will be broken topic maps. 
> Our protection
> against this to some extent is validation enforcement and a 
> strict DTD, 
> but as I've heard too many time to not have nightmares about 
> it, "market
> forces" may prevail upon us to allow for proprietary extensions via 
> namespaces, and lax validation in the DTD. The XTM 'loose' DTD.
> 
> What all this says to me is that we should be very clear 
> about conformance
> and error handling behaviour in conformant XTM processors. 
> And not too lax.
> 
> Murray
> 
> ..............................................................
> .............
> Murray Altheim, SGML/XML Grease Monkey     
<mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com

-------------------------- eGroups Sponsor -------------------------~-~>
40% off fares on  
the best airlines  
at Hotwire.
http://click.egroups.com/1/9726/4/_/337252/_/971262773/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com