Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Divorcing Data Model and Syntax: was Re: her
 > Honestly, I think that JITTs and the LMNL processing model that I described > above are doing exactly the same thing -- forming a bridge from a syntax to > a data model -- but we're thinking about it in different ways -- you as a > single process that takes you from the syntax to the data model, me as a > sequence of processes that eventually get you there. > > In any case, the discussion is really helpful for me -- I find the > relationship between the reified LMNL layer and the LMNL data model, and > especially the consequences for the APIs that I'm putting together, hard to > wrap my head around at times. This discussion is really helping me to > clarify that in my own mind, even if I'm not succeeding in clarifying it in > anyone else's :) And here, I believe, we arrive at the nub: of the Three Abominable XML-DEV Permathreads, we are not really engaged in an iteration of Syntax vs. Semantics, but of The Proper Processing Model. Jeni and Patrick may make assertions about data models and about syntax, but all of their examples turn immediately to their different forms of processing. Is there any disagreement that 'process . . . takes you from the syntax to the data model', or as I usually phrase it in the permathread, semantics are elaborated from syntax by an instance execution of process? If we agree on that much, then we can accept either Sam's assertion that there is no data model, or Jeni's that there are many. Between syntax and model lies the execution of a process, as likewise between a model and some serialization of it. I will continue to insist that syntax, or more exactly a concrete instance expression of syntax, comes first. Others may prefer that the fluid preverbal Gestalt prompt each such utterance. With JITTs and LMNL we are presented with two new paradeigmata, realized and expressed as processes. Those processes each imply an underlying data model and each has naturally convenient forms of serialization syntax. IMHO designing this sort of process is precisely what we, as XML developers, can best do with the XML 1.0 Recommendation. Throughout that document are references which look ahead to XML processors to be built upon it. Parsers are mere ancillary utilities to such processors, and the design of APIs can become a distracting alternative use of the time and effort which might otherwise be invested in implementing XML processors. It is high time that we are now building processors on various models implied by the XML 1.0 Recommendation. Respectfully, Walter Perry 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
