> So there is no reason I couldn't use XPath to find the colour of the 53rd
> pixel on the 22nd row:
>
> /screen/pixels/row[22]/pixel[53]/@colour
>
> Or something or other like that! Anyway, the point is that the underlying
> data need not be stored in some memory-hungry, pointy-bracketed
> structure--it can still be the very efficient manner used for screen
> pixels.
> But the layer that provides access to the pixel (now a 'node' with
> properties represented by 'attributes') could be an XML-family layer. This
> provides a powerful layer of abstraction.
>
That's a VERY COOL concept! I hadn't given thought to the ability
to use tools such as XPath on data not in XML...
I do things like this for myself, though not using "pure" XPath - I
think I'm going to go investigate how to put a "wrapper layer" on top of my
underlying formats to expose them to standard XPath (and similar) tools.
Thanks!!
Leonard
------------------------ Yahoo! Groups Sponsor --------------------~-->
1.2 million kids a year are victims of human trafficking. Stop slavery.
http://us.click.yahoo.com/.QUssC/izNLAA/TtwFAA/1U_rlB/TM
--------------------------------------------------------------------~->
-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
