Re: [Gzz] Review of markup_xhtmlmodularized--tjl

[Tuomas Lukka]

On Wed, Apr 09, 2003 at 08:43:15PM +0200, Benja Fallenstein wrote:
> 
> (As far as I can see, you have not posted this PEG on the list. Quoting 
> extensively.)

Oops... 

Below, I've not answered the questions I put in as issues.

This PEG obviously needs a *lot* of thought, and possibly a different
approach.

> >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 idea of semantic markup is of course that no-one will want to
italicize it, only emphasize it ;)

The point is just to start really small.

> >the Style Sheet module, and the Style Attribute module.
> 
> Style sheets are probably going to be hard work...

Why especially?

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

If anyone knows XML and DTDs really well, would be a good job for them..
Volunteers?

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

No support for the xanalogical text methods, and 
seeing a sequence of spans as a single string.

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

It might be a good option, *but* then someone'll go and edit that
HTML with an uncomprehending editor...

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

<img> is in the same namespace as <span>...

        Tuomas