Re: id field

On Monday 10 of November 2003 18:18, Peter Bienstman wrote:
>
> Actually, what's wrong with the current implementation?

Well, I am implementing XML load/save format for the core (this will be in a 
module later, but nevertheless - it's part of the core - I think about it 
"core modules").
Now, there is a small problem - id has to be saved somehow.
My initial idea was to put it CDATA and don't think about it at all (just load 
and save it), from the core programmer point of view.
Yeah, this would work. (And I will back to this solution if we won't find a 
better one, and there is really need for this additional field ("id")).
But this would also bloat XML format (less readable file, more data to save/
load/send, more code in core), so Bruno suggested to use "id" as attribute of 
<memaid_data>
This would require some more care from the core - some characters won't be 
allowed.
Not a problem, but thinking more about it:
if "id" has just be an unique string/number (this was the original Richard's 
request), then the core should take care of it and make it always unique - 
this way everybody would have unique id for "free" from the core itself.

Now the best would be to have it as a number, no characters are allowed at 
all.
(Rationale: a number (instead of a string) is the simplest and fastest 
approach in many ways, from the core point of view).

And ok... solution is easy. (e.g. to take current unix time as a "id").
But I now ask: does anyone really use it, or will use it?
I'm just afraid it could turn out that I work, implement and bloat code and 
format of element.xml, by something that will be never used by anyone.
(Richard was the only one who asked for it, and now he doesn't respond, I 
guess he is on some sort of vacation;).
"Make everything as simple as possible, but not simpler." by A. Einstein is my 
motto in programming.

*If* it can be useful - than just tell me how, and I will stop whining, and 
will just implement it in XML format. 

> Just provide a
> string for people to do extra stuff with if they want, and completely
> ignore it in the core, apart from loading and saving it. No extra code
> necessary.

Well. Any change of format is a good occasion to think about changes in 
general. As we break some compatibility, this is an occasion to introduce 
more changes without breaking it more.

If people use "id" as "id string" then why core shouldn't support it? (provide 
an unique number by it's own) - won't it help those who need a "id"?
And, OTOH, if nobody use "id" field as a "id string" then maybe we should 
think how people use it for, and if core can support it somehow?

> If having an 'id' element is a problem with reserved keywords in XML, then
> just rename it to 'descr' or whatever when exporting the XML.

But is anyone use "id" as a description field?

Dave



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/