World: r3wp

I mean, it's a solvable problem. IN could theoretically be enhanced 
to also accept paths, but, iIrc, Carl wasn't keen on the idea because 
he wanted IN to remain simple and fast. He said something like "it's 
for words".

The only thing we can do is make our own mezz version of IN that 
accepts paths.

(Ok, it's not a solvable problem for paths with dynamic elements 
in them like functions, but of course, there are many more "static" 
paths which this would be darned useful for.)

GET and SET work with paths in R3. Perhaps as you describe could 
be added as well, to handle the IN function for paths. And functions 
wouldn't be traced through.

the problem with object/path/to 'rebol is that it assumes object/path/to 
exists

Yup.

So you have to check for 'to in object/path first, and so on. I didn't 
say it would be a fast mezzanine :(

The way this kind of thing is resolved in R3 is through liberal use 
of the ASSERT/type function, and not representing XML as objects.

I guess there's a lot of advantages to just using blocks ... as it 
is now, some elements in my object are blocks and some are objects 
which makes it very messy

OTOH, blocks could get messy too ...


at present I have structures like ccr/body/alerts/alert where alert 
can be either a single alert object, or a block of alert objects

Ideally if I were to use blocks, it would end up that alert is always 
a block .. 0 ... n blocks

The R3 GUI is structured as a mix of objects, maps, blocks and gobs, 
but it is very consistent and not messy.

I presume it can't change though ... if a particular item is an object!, 
it won't be a block of objects in another instance ....

very consistent
, yes :)

That's my issue ... because the standard for the data has not been 
tightly defined, there are varying implementations leading to somewhat 
variable structures

Sounds like you need a tighter definition, or to resign yourself 
to slow code.

It's an ASTM standard ... I can't change the XSD!

But you can use a consistent REBOL representation of it, and don't 
need objects.

Google health has solved the issue by only working with a subset 
of the XSD.

Well, you can clean it up to a usable structure on read, process 
it nicely, then regenerate the bad XML on write.

Yeah .. I guess I was getting to that.

I suspect this is a very common issue and not bad xml.  So, if the 
XSD states an element can be 0 ... n and each element can be of a 
different type, then it's going to be difficult to work with no matter 
what.

If an XSD states that; it should always be a block even in the single 
object case.

I guess the xml-to-object.r script doesn't know that!

I never liked that script :(

(no offence intended to whoever wrote it)

Saw a new language the other day that has a native, literal data 
structure which matches the XML object model, without the syntax.

Nice language - clean and small, pretty to look at, compiles to native 
code.

Given 


>> obj: make object! [ Description: make object! [ Text: "REBOL" 
]]
>> path: 'Description/Text
== Description/Text


How can I find "REBOL" without breaking the path into it's constituents?

I'm guessing that there's something very simple ... but in the meantime


get-value: func [ obj [object!] path [path!]
	/local id
][
	if not empty? path [
		either all [ id: in obj path/1  obj: get id  object? obj ][
			remove path
			get-value obj path
		][
			obj
		]
	]
]

>> get-value obj path
== "REBOL"

Is this a bug or a feature:

>> to integer! ""
== 0

>> to decimal! ""
** Script Error: Invalid argument:
** Near: to decimal! ""

R3 returns a bug with the first one, but it could be intentional 
in both R2 and R3.

It was an intentional change. TO has been cleaned up a lot in R3 
- the error there tells why:
>> to integer! ""
** Script error: content too short (or just whitespace)

R2 also works with
  to integer! #
but  not
  to integer! %
Looks like a consistency bug in R2 that has been fixed in R3.

Oops -- Brian beat me to, and gave the definitive answer to trump 
my late speculation.

The R2 behavior is more of a "feature": Buggy behavior that you can 
count on remaining in R2 for compatibility reasons.

Almost every day I come across another reason to appreciate bug#666 
:)

How can i redefine 'now so that it takes into account an offset ( 
which is only calculated once ) .. without causing a stack overflow!

I guess I need to copy the function block of 'now ... but can you 
do that with natives ?

SPEC-OF works on natives too :)

Remember to keep a private reference to the old NOW, or at least 
reference it through system/contexts/system/now. When you set 'now 
in a user script it will copy the value of 'now to the user context 
(system/contexts/user), and then you will be reassigning it there.

spec-of ??

sounds like a R3 function

Oh, sorry, I backported it. Try this instead:
    copy/deep third :now

I forget sometimes when R2 doesn't have the new functions since I 
mostly work with R2/Forward (the backports).

And isnore the user-vs-system context thing too.

isnore -> ignore

you're having a dyslexic day :)

Bad typing day :(