World: r3wp

My positional version handles multiple subelements of the same type, 
and using strings rather than words lets you use tags that don't 
match word syntax or are case=sensitive.

its just that in my tests, either you can create, read or set some 
of the datatypes via path notation.  so only string based types allow 
full XML qualification.

hahaha

XML can be case sensitive??

but brian, how do you acess it?

by position!

XML *is* case-sensitive. Your paths can't access multiple subelements 
of the same type, or embedded text.

I wrote a simple xpath compiler too (but don't know where it is now).

I wanted direct access to all elements within rebol.

Looks like we need an article on best practices here ...

a later version, using schema validation, understands multiple subelements 
and automatically converts them to blocks IIRC.

so you do document/element/3/subelement/#attribute.

Your paths can't access multiple subelements of the same type, or 
embedded text. It might have worked for that customer but not the 
general case. No namespace support either.

my paths.. namespace works... for sure.  did you know you can have 
colon in word names in R2 !   but i didn;t use that, I just used 
tags directly.  more obvious than strings, and the exact same effort 
and speed.

I was parsing xhtml and other XML of the like. Subelements of mixed 
types in order with text between them than mattered.

my engine does support embedded types, but ignored it by default... 
it was also byte reversible... a loaded xml block loaded through 
the engine was saved back exactly, byte for byte, checksum proofed.

oops.. embedded text I mean.

but all of that is not open source.

And mine is lost :(

my newer version doesn't have the schema validation process.... that 
is a very complex engine to build.   schemas and Parse traversal 
do not follow the same algorythm... so its a bitch to implement.

anyhow... the xml tools I currently have are not yet tested enough 
to be release ready.

Ok, so we have established that everyone does it their own way :)

but the rebxml tools (on rebol.org) as-is are very usefull, so some 
utf-8 support and are less buggy than rebelXML in my previous tests.

rebelxml gets confused if there is more than one path with the same 
name

it accepts the first one it finds

even if the full path is specified.

I suspect the author is no longer reboling

I remeber it also tripping on some of the XML files I gave it... 
don't remember the problems... but its error handling /recovery was 
very shaky IIRC.

You should add a comment to the discussion page if you remember.

as should i.

read above,  I don't  ;-)

at this time .. it may come back to you

that's why I said "if" ...

Using objects means i can store the functions that initialize it 
inside the object.

Not a good idea for data objects, which could number in the thousands, 
each with their own bound copy of the functions.

yes, the best method is to have some form of dtd or schema, and use 
class-based objects.

Class-based objects are emulated in REBOL.

the init is a context with one function, to which you supply the 
outer (instance) which holds the data:

my-tag: context [
	data: "tototo"
	attribute-1: "red"
	class: context [
		init: func [instance][
			instance/data: copy ""
			instance/attribute-1:  copy "blue"
		]
	]
]

to init the an instance of my-tag:

new-tag: make my-tag [class/init self]

class is shared amongst all my-tag instances, and is never bound 
to any of them, so its both very fast and very RAM efficient..  exponentially 
so with large classes.

That's what i was going to do initially, but I thought it would be 
easier to maintain if I kept the init methods inside the objects

Perhaps I'm not clear on this ....  
If I create a pharmacy object like this


pharmacy: make object! [
	name: none
	init: func [ n ][
		self/name: n
	]
]


is the init function shared by all the subsequent pharmacy instances?

it is bound each time, so if you have 2000 instances, you actually 
have 2000 times that function in ram, it adds up quickly for larger 
objects... for such a simple object, it might not be all that bad...

what's the diff between yours and mine?

my example above, will share the init function amongst all the 2000 
objects... and its going to be faster since no binding occurs... 
well only the CLASS word is bound but its content is the same in 
all instances.

with liquid the difference is staggering when over 10000 objects.

well, I doubt that I would have more than a few hundred objects... 
but ...

unclear as to why yours is shared and mine isn't

but its a large object.  still using the class system, I can allocate 
1000000 nodes using about 400MB.  with instances, 10000 obects take 
much more than that.

R2 shares objects within objects. the class is not re-created at 
each make [].

Oh ....

is it objects within objects within objects?