XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] 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
kurt.cagle@gmail.com
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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS