frebe73_at_gmail.com wrote:
>>>html(docid, title, bodyelementid)
>>>element(elementid, seqno, parentid)
>>>form(elementid, action)
>>>input(elementid, type, name, value)
>>>table(elementid, border)
>>>tr(elementid, rowno)
>>>etc etc
>>
>>I guess what I meant was a specific example of a body of data, one or more
>>rows from one or more tables, converted into a body of HTML. If you gave
>>an example of a starting point and an ending point, I might begin to get a
>>feel for how you would picture jumping from one to the next. The data
>>should be customer data, like orders, not data from a HTML schema like the
>>one above.
>
>
> The starting data could be an employee table.
> employee(employeeid, firstname, lastname)
> With the content
> employee(1, "Donald", "Duck")
> employee(2, "Kit", "Walker")
>
> The end-point might be tuples describing the html page.
>
> html(1, "Employee list", 100)
> element(100, 1, null)
> element(101, 1, 100)
> table(101, 1)
> element(102, 1, 101)
> tr(102)
> element(104, 1, 102)
> td(104, "Donald")
> element(105, 1, 102)
> td(105, "Duck")
> element(103, 1, 101)
> tr(103)
> element(104, 1, 102)
> td(104, "Kit")
> element(105, 1, 102)
> td(105, "Walker")
>
> The result tuples would if possible be obtained by a view (or something
> similar using any declarative relational language).
If you are creating a relational design to describe a document or user
interface, why would you choose to re-invent all of the problems of html?
Received on Thu Jul 06 2006 - 08:09:13 CDT
