[Humanist] 24.7 inadequacies of markup

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Sun May 9 07:36:38 CEST 2010


                  Humanist Discussion Group, Vol. 24, No. 7.
         Centre for Computing in the Humanities, King's College London
                       www.digitalhumanities.org/humanist
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    Wendell Piez <wapiez at mulberrytech.com>                    (41)
        Subject: Re: [Humanist] 24.2 inadequacies of markup

  [2]   From:    Patrick Durusau <patrick at durusau.net>                     (27)
        Subject: Re: [Humanist] 23.797 inadequacies of markup


--[1]------------------------------------------------------------------------
        Date: Fri, 07 May 2010 10:06:00 -0400
        From: Wendell Piez <wapiez at mulberrytech.com>
        Subject: Re: [Humanist] 24.2 inadequacies of markup
        In-Reply-To: <20100507053200.43646549DF at woodward.joyent.us>


Randolph,

You wrote:
>--[2]------------------------------------------------------------------------
>         Date: Thu, 6 May 2010 15:14:53 -0700
>         From: "J. Randolph Radney" <jrradney at gmail.com>
>         Subject: markup
>         In-Reply-To: <20100506053456.7F2A655317 at woodward.joyent.us>
>
>
>What would be the possibility of a 'layered' markup, following the analogy
>of Google Earth's layers of terrain display? Could levels of 'interpreting'
>be agreed upon whereby users could 'turn on' certain layers for certain
>purposes and turn them off for others?

It's funny you say this, inasmuch as LMNL stands for "Layered Markup 
and Annotation Language". (The name -- pronounced, by many of us, 
"Liminal" -- also gestures towards how it can serve as something 
halfway between a raw text stream and a more fully controlled data 
structure. As befits a markup language meant for messing around, it's 
kind of slippy-slidy unless you assert control.) Moreover, absent a 
set of constraints for relating them (which an application is free to 
impose or not as it chooses), ranges in LMNL have no inherent 
relation to one another to prevent you from calling them in and out 
as you like. (You can leave out any set of ranges without discarding 
the text in them: unlike elements in XML, a LMNL range can't be 
identified with its contents, but only makes an assertion about them.)

Where's the rub? We don't know, but I expect it is in performance and 
scalability. On the other hand, we have also taken care to specify 
LMNL in such a way as to avoid any obvious clashes with XML (LMNL as 
an XML datatype?), which (along with other optimizations yet 
undiscovered) could help deal with this.

Cheers,
Wendell

==========================================================
Wendell Piez                            mailto:wapiez at mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in SGML and XML
==========================================================



--[2]------------------------------------------------------------------------
        Date: Sat, 08 May 2010 10:42:11 -0400
        From: Patrick Durusau <patrick at durusau.net>
        Subject: Re: [Humanist] 23.797 inadequacies of markup
        In-Reply-To: <20100506053456.7F2A655317 at woodward.joyent.us>

Desmond,

You write:

<snip>
>> You have added the requirement that we do something "...for
>> interpretative readers in real time."
>> Another clue that you are talking about interfaces and not markup.
>>      
> You appear to assume lightly that there is a clean separation between markup and interface. As if the choice of the former as a medium had no influence on what types of interface you could create. For example, I find it hard to see how the editor of a cultural heritage text, to which markup has been subsequently added, can avoid interacting with the markup directly and being influenced by the limitations that imposes on the interface.
>
>    

It was Willard's point that we need to do something "...for 
interpretative readers in real time." that goes unexplained.

You have some default "plain text view" that includes markup.

What seems to be missing is a realization that a "plain text view" is a 
display decision someone made.

As I recall, even the early versions of WordPerfect had a display/hide 
codes feature. I am sure even earlier than that but I don't recall the 
names of the software.

Hope you are having a great weekend!

Patrick

-- 

Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)





More information about the Humanist mailing list