[Prev][Next][Index][Thread]

Re: 4.c Homegrown locator language?



David Durand wrote:
> 
> At 12:33 PM -0800 3/4/97, Tim Bray wrote:
> >4.c The spec will describe some addressing types that we support.  Should
> >we be open-ended and include a way to support other user-defined
> >locator languages?
> 
> No. The fact that we are defining generalized markup means that users can
> define their own locator languages if they want to -- and have the same
> level of interoperability with the rest of the world (none, without prior
> arrangement). If they want a way to generalize things, they can use HyTime.
> 
> For XML linking, no effective purpose is server by knowing that something
> is a locator, if there's no guarantee that it can be resolved.
> 
> We should keep XML linking as a specific architecture, not a toolkit. XML
> is a toolkit, and allows for flexibile private arrangements, so lets keep
> links simple and only include features that we are wiling to require of xml
> linking implementors.

I agree with David particularly with regards to an XML 1.0 version.  An
easy to 
use but more powerful than current applications version is needed.  I
think it 
important to emphasize if not in the spec language, at least in the
presentations 
that XML Linking is more like TEI and less like HyTime in this:  XML
Linking 
is an application.  It is not a user-extensible meta-language standard
in the 
way that XML syntax is.  That is why some of us asked for separate
documents 
and refer to XML as a suite.  The user certainly can use XML syntax and
create 
another similar or dissimilar link and location application.   Nothing
can 
prevent that nor should anything.  XML Linking is a set of application
conventions 
that a user community agrees to and agrees to implement.  Its success
will depend 
on who adopts it and uses it.

Now can someone add their own extensions to the XML Linking
applications:  certainly.
Who will use those extensions?  That is up to the market.  Will they
pass a 
conformance suite test set?  No.  Could they be offered as improvements
to 
XML 1.n?  Certainly.  That is the way it should work.  Will this
guarantee 
future interoperability?  No, but nothing short of a big stick does that
and 
even then, it doesn't work when someone can bear the pain.

len


Follow-Ups: References: