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

RE: Simplicity of XPath

• From: "Bullard, Claude L (Len)" <clbullar@i...>
• To: Derek Denny-Brown <derekdb@m...>,Matt Sergeant <matt@s...>, xml-dev@l...
• Date: Mon, 13 Nov 2000 08:50:52 -0600

I agree.  What seems to be hard for those I talk to 
is keeping the context in mind.  They are often not 
quite sure what object they have at hand and spend time 
testing each statement until they are sure just what 
is in memory "now".   This takes practice.  The heavily 
bracketed syntax with abbreviations as noted elsewhere 
also takes some getting used to.

Getting organizations to agree to any description which 
becomes a process control is of course and ALWAYS has 
been the hardest problem of markup.  The RiceBowl: those 
who have solutions for problems defend the problem.  "Same 
as it ever was, same as it ever was."

The tool MS just provided with the web-based working 
examples of each XSLT function and statement is very 
useful for exploring and understanding the language. 

Len
clbullar@i...
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Derek Denny-Brown [mailto:derekdb@m...]

I actually think that people have problems with XPath for 2 reasons.
Obviously, these are not the only reasons, but these are the primary
difficulties I have percieved in working with people using MSXML.

1) The only way to use it is in XSLT.  
-The reason I say this is because a have encountered *many* developers who
depend heavily on MSXML's selectSingleNode() and selectNodes() calls, often
using those as an alternative to pure DOM calls.  I very rarely see
complaints of confusion from these users, while I regularly see people
struggling with XPath in the context of XSLT.  The developers using
selectSingleNode() and selectNodes() found that this was easier to code, and
produced less fragile code, than just DOM core.

2) XPath is set-based, but has a syntax which resembles common path
navagation syntaxes which are not (file paths/URLs)
-I have encountered confusion over the fact that "a/b" matches a set of <b>s
which may themselves be inside different <a> elements.  People usually can
keep track of the set semantics for the outer-most level ("/b" in the above
case), but forget that it applies to the entire path.

• Prev by Date: RE: Subsetting/ Canonical Parsers/ XML Compliance/ etc.
• Next by Date: RE: Dangers of De Facto (WAS RE: Dangers of Subsetting?)
• Previous by thread: RE: Simplicity of XPath
• Next by thread: Dangers of De Facto (WAS RE: Dangers of Subsetting?)
• Index(es):
  • Date
  • Thread