[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Highly Declarative Designs

  • From: Kurt Cagle <kurt.cagle@gmail.com>
  • To: Frank Manola <fmanola@acm.org>
  • Date: Sat, 5 Feb 2011 16:33:34 -0500

Re:  Highly Declarative Designs
I'd make the case that a given design is declarative would be the same as declarative programming elsewhere. A design is declarative if there exists a representation of that design for any given state that fully describes that state. Put another way, there are no side effects that represent hidden or unknown state within a declarative design. In this regard, a regular expression and an XPath both represent declarative functions - performing a regular expression upon the same string or an XPath upon the same XML document should always return precisely the same expression every time. The complexity of either is immaterial ... the important aspect is that there are no side effects that will provide different answers if the same queries are applied to the same data.

In the real world, of course, it's often very difficult to achieve purely declarative design. A web service call, for instance, may very well provide different data based upon when the invocation is made. The random function is, almost by definition, non-declarative - ideally, it will never return precisely the same value (although it can be argued that seeded random functions are consistent in the series of values, but that series is, presumably, nearly infinite in extent). Time functions, similarly, are non-declarative. Note that they can certainly be used as inputs to a declarative process, but it is the specific value of that function that is the input, not the function itself.

Kurt Cagle
Member and Invited Expert
XForms, HTML Working Group
World Wide Web Consortium
443-837-8725



On Sat, Feb 5, 2011 at 3:29 PM, Frank Manola <fmanola@acm.org> wrote:
Roger--

It seems to me you need to amplify a bit.  For example:

a.  You seem to be making a sharp distinction between "navigating markup" and "processing data".   But why isn't navigating markup (or searching through any other kind of data structure) "processing data"?   Do you have some specific kind of "processing" in mind when you make this distinction?

b.  Further to (a), in your discussion you talk about "processing" regular expressions as opposed to "navigating" markup.  While there's certainly a distinction here, aren't regular expressions "declarative", and aren't you also "processing" the markup (different syntax, but still processing)?

c.  After one extremely simple example, you conclude with a recommendation "Wherever possible, use highly declarative designs".  I suppose the "wherever possible" gives you some wiggle room, but still it seems you're making this recommendation with little or no consideration of what the problem is, or what the tradeoffs might be.   Do you really think, for example, that navigating an extremely large file of markup is *always* better, considering time and space tradeoffs, than doing a simple computation?  Or that navigating an extremely large file of markup is always better than "processing" (to use your term) some other data structure that might be better adapted to the problem?  Suppose, for example, the question you wanted answered had to do with the structure of the family name (say, for a start, whether spaces were allowed)?  Can you give us the markup that conveys all the information conveyed by the regular expression (without using the regular expression) and show that navigating that markup is preferable to "processing" the regular expression?  Or, going at this another way, under what circumstances would it not be *possible* to use a highly declarative design?

It's one thing to point out that one might want to consider "highly declarative design" as one tool in a "designer's toolbox".  But it seems to me you've gone well beyond that.

--Frank



On Feb 5, 2011, at 9:17 AM, Costello, Roger L. wrote:

> Hi Folks,
>
> Issue: What are the characteristics of a highly declarative design?
>
> I propose this as a characteristic:
>
>    If you can ask a question and get the answer by
>    exclusively navigating markup, without any processing
>    of data, then you have a highly declarative design.
>
> More ... http://www.xfront.com/Highly-Declarative-Designs.pdf
>
> Comments welcome.
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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.