Re: [Gzz] PEG about simplifying xanalogical text

[Tuomas Lukka]

On Thu, Feb 20, 2003 at 06:29:35PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >On Mon, Feb 17, 2003 at 07:10:41PM +0100, Benja Fallenstein wrote:
> >This still needs thinking from a security
> >etc. perspectives,
> 
> Could you elaborate?

Not too much; I get a funny feeling of not being convinced that
it's secure and not liable to be misused somehow.

> >and that's why I'd like it to coexist with
> >our current textspan implementation.
> 
> May work.
> 
> >Happily, that's very easy to do: just make another class
> >implementing TextSpan and a new SpanMaker etc. 
> 
> Unfortunately not: TextSpans have a TextScrollBlock, which has a 
> getSpan(int, int) method we cannot implement here.

That's not the troublesome method; getCurrent() is the main culprit.

How about allowing getScrollblock() to return null?
And adding getScrollId() for the other one.

> >>second, make
> >>text enfilades a data type disjoint from "media"
> >>(images, PDF, etc.).
> 
> (You haven't commented on this. In which of the two PEGs should it go in 
> your opinion, or do you feel there should be a third?)

I thought it was the second one... that's where you're separating
text and images anyway. But I'm not sure I understood everything correctly
then...

> >>If we move to RDF, we could transclude a PDF as follows:
> >>Create a node to represent the image; refer to the block
> >>through a 'load-from' property (the block is a RDF node, by virtue
> >>of having a URI); also give the page number(s) and coordinates
> >>you want to transclude, as other properties, if you don't
> >>want to transclude the whole block.
> >
> >No, this is how we used to do image spans and it was horrible.
> 
> Easy answer: Ok, we can use yet another form of RDF literal type for 
> this, containing a single XML tag like
> 
>     <img src="<storm-urn>" x="0" y="0" width="112" height="114"/>
> 
> Hard answer: I think you may be projecting-- we did something like this 
> and we had problems --> this causes problems. What we need is to find 
> out why exactly we had problems before, so that we can see whether it 
> will cause the same problems in this situation. Or maybe you have this 
> readily in mind, but I don't.

Yes, true, the problem was in the lack of proper encapsulation in
the space objects.

So can you give a suitable set of API changes here?

        Tuomas