Re: [Gzz] PEG about simplifying xanalogical text

[Benja Fallenstein]

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?

> 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.

> > 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?)

> > 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.

My perspective--

What we did:
We had a horrible way to do text (vstream dimensions). Then we had a 
getSpan() method in space, which would return nothing for vstreams. But 
if we connected the cell in a certain structure, other cells would be 
read to contain the scroll block id, width and height (all as vstreams). 
setSpan() would create such a structure. Our views would look whether 
getSpan() returns something, and if so, show it instead of a cell's vstream.

Why this caused problems:
Firstly, because we had such a horrible interface. getSpan() for images 
vs. the vstream dimension was twisted and twangled and hard to 
understand. Depending on what a cell contained, you would have to use 
different methods to access its contents. Plus, the Space object had to 
know about structure, because getSpan() fell in its responsibility.

Secondly, because of the concept that a cell contains something. We'd 
think of a cell containing either text or an image. This made having 
different, orthogonal mechanisms for the two difficult-- to find out 
what a cell contained, you'd have to look for both things.


Now, with RDF (which I was talking about), things are different. First 
off, in the model, nodes do not contain text. Rather, they are connected 
to text literals. Therefore, you do not have the question, "what does 
this node contain?" Rather, you have some nodes which are literal nodes, 
which contain ("are") text and nothing else.

Similarly, you would have span nodes, which contain ("are") an 
image/page/... span and nothing else. These nodes would *not* contain 
text. They would be of the RDF class ImageSpan/PageSpan/etc. If we have 
a 'contains' property to designate what's 'contained' in a cell, the 
value of this property could either be a xutext literal or a media 
span-- so we could have a single mechanism for node-contains-media for 
both text and other media.

The coordinates would be represented as integer-typed literals connected 
to the span node. The block would be represented by the node whose 
URIref is the block's (canonical) id. The mechanism wouldn't be built on 
top of Xu text, because the literals would be integers, not Xu text (not 
all RDF literals should contain Xu text because this would be 
embracing&extending RDF-- see my 'structure proposal' mail).


In summary, I don't think that the earlier problems apply to this. But 
as I said, we could also use literals containing <img/> tags. So why do 
I argue this point anyway? Because of the realization that we could *use 
the structure to resolve links and transclusions*. Maybe there really 
are big problems with this approach that I don't see, but if not, this 
seems to be a pretty strong argument, keeping the code simple and so on.

> Could we split the PEG, as these two things are very orthogonal and
> at least my opinion on them is very different?

Fine. (Except as I already asked above, where should the third issue-- 
disjoint 'text' and 'media' types-- go?)

- Benja