[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: he

  • To: "XML DEV" <xml-dev@l...>
  • Subject: RE: Re: Divorcing Data Model and Syntax: was Re: heritage (was Re: SGML on the Web)
  • From: "Keith W. Boone" <keith@w...>
  • Date: Mon, 7 Oct 2002 13:08:12 -0400
  • Importance: Normal
  • In-reply-to: <3DA1B755.69F8C066@f...>
  • Reply-to: <keith@w...>

RE:  Re: Divorcing Data Model and Syntax: was Re:   he
I think you miss the point of Jeni and Patrick's work.  The Syntax of XML
does not allow for overlapping markup, something Jeni, Patrick, myself and
others have to deal with on a regular basis.  LMNL and JITTs both provide
mechanisms to resolve those problems.  If these problems aren't the ones you
need to deal with, it doesn't invalidate their approach or the results.
Forcing their problems into using an XML 1.0 syntax ignores the requirements
of their problem, and for what purpose?  To fit the work into something that
can be used in XML?  Why is that necessary?  They've both extended the
notion of markup in such a way as to provide for a missing capability in
XML, the ability to use overlapping markup.  Sure, you could develop an XML
syntax that models their data in such a way as to provide for an XML
serialization of it, but that ignores the human requirements of being able
to easily interpret and edit that markup [remember, none of this is
important without humans... ;-)]

FYI, Most of us routinely build processors over the various models implied
by XML 1.0.  We wouldn't be writing/listening here if we didn't.

Respectfully,

	Keith W. Boone

Engineering is what happens when science and
mathematics meet politics.  Products are what
happens when all three meet reality.

-----Original Message-----
From: W. E. Perry [mailto:wperry@f...]
Sent: Monday, October 07, 2002 12:33 PM
To: XML DEV
Subject: Re:  Re: Divorcing Data Model and Syntax: was Re:
 heritage (was Re:  SGML on the Web)


> 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



-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.