Why do we need DoomEdNum's in UDMF at all?

[MartinHowe]

Maybe I am missing something here.

UDMF with its textual map format overcomes many limits of the game. However, even then keeping track of DoomEdNum's is a pain. It's quite difficult either randomly assigning them and incrementing, or grouping by ranges. There doesn't seem to be a "next available DoomEdNum" function in DoomBuilder (in the script editor when a DECORATE is loaded) like there is for tags. In fact, DoomEdNum's are artificial indexes having no direct relevance to the classes they represent and any number could be used to represent any class, making the assignments completely arbitrary.

So what I don't get is why, in a textual map format, do we need DoomEdNum's at all?
Why can't we simply place map objects by class and have done with it?

Does anyone have any insight into this?

[Graf Zahl]

Class names are a ZDoom feature. Using them would make the format non-universal.
Check ZSDF vs. USDF. There is was necessary to make it incompatible because unlike maps you normally write those by hand and having to resort to IDs would have been a mess.
Furthermore, DoomEdNums can be remapped, so you got an indirection in there.

[MartinHowe]

Thanks, I can see that now. Will google ZSDF and read up on it.
EDIT: Done.

As an aside, what practical use does remapping have?