[Gzz] Review of markup_xhtmlmodularized--tjl

[Benja Fallenstein]

(As far as I can see, you have not posted this PEG on the list. Quoting 
extensively.)

> =============================================================
> PEG markup_xhtmlmodularized--tjl: 
> =============================================================
>
> :Author:   Tuomas J. Lukka
> :Last-Modified: $Date: 2003/04/08 20:31:05 $
> :Revision: $Revision: 1.2 $
> :Status:   Current
>
> Marked-up text has always been a difficult but focal point for us.  
> This PEG proposes using some modules from modularized XHTML
> to accomplish it.

Sounds good. However, you should say what 'modularized XHTML' you refer 
to. AFAICT, it's XHTML 1.1.

> This PEG extends the Alph PEG ``styled_text--benja`` by providing
> a concrete proposal of the implementation of the "formatted xanalogical text".

No, it doesn't; it contradicts styled_text--benja. That peg proposes an 
object containing a list of characters each of which has a list of 
styles attached (efficiently stored as an enfilade). That's not what 
you're proposing.

You PEG agrees with the intents of styled_text--benja, but not with the 
proposal. What the proposal in my PEG tries to archieve are objects 
where e.g. ``s == s.sub(0, 100) + s.sub(100, s.length())`` trivially.

Issue: Does using XHTML with the proposed API make styled text too 
difficult to use (too different from strings)?

Issue: How is copy & paste done in your proposal? Copying over a 
paragraph boundary, and pasting that somewhere, should insert a 
paragraph boundary where it is pasted-- how to represent the copied part 
as XHTML?

> Changes
> =======
>
> The only module suitable for the current proposal appear to be the Text module,
> possibly subsetted at first from the Inline Phrasal.

I don't understand the second part of this sentence. 'Subsetted from'?

> In the future, we should probably consider next the List module, the Presentation module, 

Why these not yet, particularly the Presentation module?

Having no presentational markup and no extension mechanism for the 
semantic markup will only leave people who want to italicize text to 
emphasize it-- using presentational markup directly is better than that.

> the Style Sheet module, and the Style Attribute module.

Style sheets are probably going to be hard work...

> For example, the following would be a legal marked-up xanalogical text fragment.
> The namespace ``h`` refers to our subset of modularized XHTML and the namespace 
> ``a``
> to the alph namespace.
>
>     ...<a:ts b="..." s="15" e="20"/><h:em><a:ts b="..." s="20" e="22"/>
>     <a:uts b="..." s="42" t="[his]"/></h:em>...

Could you please PEG the Alph XML, btw, so that we can discuss it?

> This shows two text span types, and 
> how the ``ts`` span has been split by the onset of the emphasis.
>
> We need to define a suitable API for accessing the text. A miniature variant of 
> DOM,
> with xanalogical operators, seems appropriate.

Why is DOM not appropriate? Why *add to* it?

It seems better not to use a subset of DOM but the standard Java 
interfaces, so that DOM-enabled applications can use our representation 
and we can run on top of DOM-enabled applications.

It seems better not to add to DOM since that means a) total 
incompatibility with anything DOM-based, and b) concepts unfamiliar to 
most programmers. Why not simply enclose the text that an element 
resolves to inside that element? HTML applications are expected to 
extract the content from tags they do not understand anyway.

> First, some parts of DOM will be disabled for this use; in fact,
> only the classes
> Attr, CharacterData, DocumentFragment, Element, Node
> will be used.
>
> The additional node XuText will be defined; XuText corresponds
> to one or more Xanalogical spans. This implies that 
> **the alph text elements shall never be seen as DOM elements**.

Why? Issue: doesn't this make it more complex to understand?

> Also, the interface Node shall be extended by the Xanalogical 
> overlap query
>
>     boolean overlaps(SpanCollection coll);
>
> where SpanCollection is some type of overlap interface for a collections
> of unordered spans, which Node shall also implement.

> Issues
> ======
>
> - How to handle images? The img tag of the image module is not good.
>   A new alph element? What properties do we need?
>   Are stylesheets enough?
>
>     RESOLVED: New alph elements: is (imagespan) and ps
>     (pageimagespan). These elements work just like HTML's <img>
>     except for the attributes. We need the block and the x,y
>     location and w, h. For page spans, also the first page and number
>     of pages used. Pagespan layout should probably be left to the
>     stylesheet / presentation layers.

You don't answer the question whether stylesheets are enough.

I think that maybe this kind of element, which is an inline *object*, 
should be in a different namespace from the text spans, which define a 
chunk of *text* to appear in the html.

- Benja