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] The limitations of XPath and navigation for XML databaseprocessing

mike@adatinc.com wrote:
>
> Your example of XPath /A/B/C being able to be processed internally in 
> any way that is still semantically correct to optimize it could be 
> applied to COBOL and I would not consider COBOL  nonprocedural. What 
> it boils down to with me is that XPath is logically specifying the 
> logic (externally) that is needed to be performed (internally). The 
> external navigation instructions must be specified procedurally to 
> correctly define any of the possible choices for internal operations. 
> I think there is both a user and developer perspective for what is 
> nonprocedural or procedural. My article was writing to the user audience.
>

Clearly, /a/b/c can be given a procedural interpretation (start with the 
top of the document, go down to the a element, etc) or a declarative 
interpretation (pointing to c's that are found in a particular place in 
the hierarchy). If you choose the procedural interpretation, it will 
seem procedural to you. If you choose the declarative interpretation, it 
will seem declarative. I think it is generally better to teach users to 
think of it declaratively.

If you write to users, tell them that the natural interpretation is 
procedural, then complain that thinking of this procedurally isn't good 
.... there's some weakness in your argument.

Jonathan


[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