Re: [Gzz] PEG about simplifying xanalogical text

[Benja Fallenstein]

Tuomas Lukka wrote:
> 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.

How would you feel about an API that does only this for now, but can be 
extended to the more classical use later on?

My reason for asking is that I would like this to be a simplification of 
the system, and having the other option doesn't add security as long as 
it's not actually used. :-) If we could come up with a scenario where 
this is actually less secure, things would be different; but as things 
stand, I think simplicity might be preferred. What do you think?

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

Using getScrollId() and intersects()... yes, this could also work.

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

I was saying four things I guess:

1) Random ids for text
2) Separate text and 'media'
3) To implement text, use XML literals
4) To implement media, use RDF connections

The 2nd is possible without the 4th.

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

I'll try to explain what I have in mind. Fundamental assumption: RDF 
graphs don't directly know about Xanalogical text; they know about 
literals of different types. So in the most fundamental kind of view, 
you'd only see the literal values; for text, the plain XML, and for 
media, the connection to the block / the coordinates. Showing xu text 
and images would be considered a view function.

There would be different APIs for parsing xu text from an XML fragment 
and parsing xu media from a RDF node and its connections. (Our RDF API 
should store the parsed form, at least of xu text, but that needs 
thinking...) There could be an interface at some level we could ask, 
"What is this RDF node?", and it would say "a string literal" or "xu 
text" or "an image" or "a page span" or "none of the above."

Then there would be a "cell content view"-like thing that decides what 
to render inside an RDF node. There would be a dispatcher, like now, 
that would look at some node and call different other views depending on 
the node's type. This dispatcher would use the "what is this" API from 
above.

The other views would only know how to deal with xu text or only how to 
deal with image spans etc.

- Benja