Re: [Gzz] PEG about simplifying xanalogical text

[Tuomas Lukka]

On Fri, Feb 21, 2003 at 01:22:06PM +0100, Benja Fallenstein wrote:
> 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?

I don't like that; this would be removing functionality that is in line
with the original xanadu ideas.

I'd prefer to keep it, if even only for that reason, as a current alternative.

> >How about allowing getScrollblock() to return null?
> >And adding getScrollId() for the other one.
> 
> Using getScrollId() and intersects()... yes, this could also work.

Let's do this then, instead.

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

Ok, probably it would make sense to have a PEG for each.
I'd be prepared to accept 1) as discussed above, but the others
I don't understand yet well enough.

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

RDF literals are text-only, aren't they?

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

Could you formalize this to an API level?

        Tuomas