Re: (dsssl) XML not appropriate for TEI: (was Hypothetical question on namespaces)

Subject: Re: (dsssl) XML not appropriate for TEI: (was Hypothetical question on namespaces)
From: Trent Shipley <tcshipley@xxxxxxxxxxxxx>
Date: Fri, 5 Oct 2001 00:37:51 -0700
> | > Both Docbook and TEI
> | > would say immediately that XML is the way of the future...
> SGML is dead. I might wish it to be otherwise, but it ain't.

Rahtz's reply to the original flame bait indicated that he thought the 
eclipse of SGML by XML was no big deal, probably even a good thing.

If XML is indeed simpler and does everything that SGML does that is very 

Skimming over the SGML documents it looks like it was heavilly influenced by 
Goldfarb's experience at IBM developing and working on GML.  The primary 
purposes of SGML were two-fold:

1) To define a linguistic set that could be used for any reasonable markup.

2) To separate structure from implementation, as the saying goes.
2.1) One suspects that in the late 1970's and early 1980 the involved parties 
tended to focus pretty specifically on seperation of text objects and general 
communicative function versus the implementation of typesetting and page 

However, the SGML standard overshot mere *data* markup by quite a bit.  The 
-- SGML standard allows for definition of almost any lexis.
-- It has very flexible facilities for defining the morphology of its own 
concrete lexis (called the concrete syntax in the standard).
---- (One suspects that the flexibility in the concrete grammar was partly to 
ease assimilation of existing mark-up languages to SGML)
-- It has reasonably complete facilities for defining the structural, 
positional and hierarchical parts of a grammar.

XML functions very well as a language for defining data markup because the 
syntactic arm is just not that important for that function.  The flexible 
concrete lexis was even a nuisance.


I think the problem comes in when SGML is pushed into a more general language 
description language and these problems are even more pronounced with XML.


Here's a question for the guru's on the list.

Would it make sense to compartmentalize what we have now in the next major 
round of revisions along these sorts of lines.

First for each module you would have two parts:
    Part A defines the functions covered by the spec
    Part B provides details on a recommended implementation standard.

The family of standards would consist of at least these modules.

1) Lexical definition module

2) Syntax definition module.
2.1)Module for structural grammar.
2.n) Module(s) for other grammatical classes 
       (For example you might want to have a lexical extension grammar.)

4. Parse tree formation spec (GROVE)

5. Search and query spec
5.1 Parse tree traversal and query spec. (NODE regular expressions)
5.2 Data traversal and query spec.

6 Transform spec
6.1 Parse tree transform spec
6.2 Data transform spec.

   Note the absence of a style spec.  With tree and data query and transform  
    you should be able to build style languages

7. Interaction section
7.1 standard external names
7.2 distributed name resoution database
7.3 concurrency and namespaces
7.4 data exchange

8. security

 DSSSList info and archive:

Current Thread