Re: Dumb moniker questions (was Re: Bonobo dependencies ...)

[textshell t-online de]

Joe Shaw wrote:
> 
> > > My opinion is that using the octothorpe for accessing anchors
> > > in the HTML should be escaped somehow, so you could do:
> >
> >         I'm being dumb again, but what interface do you want to get from
> > these anchors ?
> 
> If you're using a browser, you can't simply ignore that they may be
> pointed at an anchor.
In a browser is is a totally different thing. The '#' commonly seen is
URLs
isn't something that actually points just to a part of that document.
The Browser
need the whole document including the anchor. It is actually something
very different
than something you could do with an moniker(to a Stream), it is an
position the browser
should scroll to after loading. I.e. the browser has to filter this
information out of
the URL before handing it to the code reading the bytes. It's sad that
the monikers use
the same character ('#') for something different. In case the moniker is
not resolving
to a stream, the facts are just a bit different: If i would like to get
an control/dom
interface of a part of an html document it should work the same way as
with documents
of another type just by using the item moniker ('!')!
Yes, this means that the URL name space is _not_ a subset of the moniker
namespace. The
moniker namesoace is a bit different, while looking much alike.

some examples (in monikernamespace):
http://www.foo.com/compress.html.gz#gzip:          the HTML document
              possible interfaces include stream, control and "DOM"

http://www.foo.com/stuff.html!anchor1             an item in the HTML
doc
              possible interfaces include control(not sure) and "DOM"
                        but no stream.

http://www.foo.com/compress.html.gz#gzip:!anchor2
              this is obviously similar to the second case, but
              the HTML document is stored in compressed form.



>                       This may only be useful against a Control moniker,
> but I could see it returning a Stream of only that anchor (or perhaps the
> rest of the HTML file starting at that anchor). I'm not saying that an
> anchor should be a whole different moniker but that the http moniker
> should do The Right Thing when given one.
I dont think it is the job of an http moniker is to care about
HTML-files
I don't think this is the way monikers a supposed to work, they are
stacked.
And anchors are not part of the HTTP or URL spec, they are defined by
HTML and
XML (don't know about SGML). This means that anchors are something that
this
component that handles HTML/XML should care about not some monikers that
just provide access to an storge (or like). You are proposing to extent
the html
moniker but what about file:/home/martin/stuff.html!anchor1?

> 
> > > http://www.foo.com/stuff.html\#anchor1
> > > or
> > > http://www.foo.com/compress.html.gz#gzip:
> >
> >         Again, what if my html is not coming via. an http transport; this
> > approach looks strange to me.
> 
> Hmm. Good point. file:///home/joe/stuff.html\#anchor would be valid, but I
> can see how that would somewhat hard to parse.
> 
> Joe
> 



-  martin