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 true. 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 description. 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: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: (dsssl) XML not appropriate for, Norman Walsh | Thread | Re: (dsssl) XML not appropriate for, Sebastian Rahtz |
(dsssl) Re: [OpenJade-devel] Re: Op, Paul Tyson | Date | Re: (dsssl) XML not appropriate for, Sebastian Rahtz |
Month |