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

Re: B.9 Formal system, public identifiers?



James Clark wrote:
> 
> At 16:27 15/10/96 -0400, David Durand wrote:
> 
> > If we specify FSI syntax, and
> >then restrict the FSIs to be URLs, there is a nice path to more-robust
> >identifiers at no more cost than we incur by implementing URLs to
> >begin with.
> 
> There is a cost to the user: instead of entering a kind of thing they are
> familiar with, namely a URL, they have to enter something that they are not
> familiar with, namely an FSI.
> 
> If we stick to URLs now, we can still support FSIs in the future: any FSI
> must include < and > but these two characters are not allowed in URLs.  It's
> ridiculous to force users to type <url> at the beginning of all their URLs
> when it's completely unnecessary to do so.
> 
> >    But making it impossible to ever do the right thing and use
> >location independent naming seems a high price to bear.
> 
> URL syntax is extensible: why can't it be used to do location-independent
> naming? Something like fpi://W3C/DTD/HTML_3.2 is a perfectly good URL.  I
> can't resolve it, but then I can't resolve FPIs either.
> 
> Location-independent naming is not a problem specific to XML.  We should use
> whatever general solution gets adopted for the WWW, rather than trying to
> come up with a solution specifically for XML.
> 
> James

The question:  are the WWW protocols the responsibility 
of any notation or any language for defining a notation?
In a framework, protocols can always be added, but for 
system integration and stability, redoing existing ones 
is expensive.

After so many years of work in HyTime, I do not wish to 
see the strong concepts of HyTime location and address types 
disappear.  

But at this time, the established WWW protocols are
in place and they work.   XML has the power to return to us the 
capability to design our own structures and use them 
as see fit in operations on the data.  To me, there
is the evolution of XML.  Version 1.0 
should be be a perfect fit to existing frameworks.
Else, it will not be adopted. 

VRML used this strategy successfully.  If we adopt 
this strategy, our interoperability problems and 
many of our portability problems are reduced significantly.

I think James is right.  2.0 is a new day.

len


References: