Re: [DAIA] DAIA 1.0: Usage of message

[Uwe R. <re...@he...>]

Hi Jakob,

here we are again, at the clashing point of our different backgrounds.
On the one side, you the top informed traveler between all standards and 
norms. On the other side me, the well grounded specialist for 
nonstandard practices in librarys, looking for pragmatic solutions.
Let us find a good compromise again :-)

You are right when you postulate
> ... the term "message" is used inconsistently in the current
> specification, ....
<message> was intended for errors. But the element became to a swiss 
knife for small hacks. So I can't really agree with your conclusion
> we may solve the issues without the <message> element.
Here my pragmatic approach. Since the usage message is already not very 
consistent, if should not hurt to use it to extend <limitation>
Yes your new element <content> may be a more proper way of modeling, but 
is is a additional element and worse it would the second which explicit 
is meant for plain text. For me this is a anti pattern to "Don't repeat 
yourself"
Btw. For me, <message> was always meant as container for end user 
messages, why else should it contain the 'lang' attribute?
Btw2. If you have a look at the context the usage of <message> isn't 
really inconsistent. Its like fully qualified names, "org.foo.message" 
is different to "org.bar.message".

I think, we have still the same fundamental idea. "A perfect 
implementation of DAIA should not need to code any information as plain 
text." (This is already possible.)
I hope we also agree with, that most implementations aren't perfect and 
there is a need for text containers.
Your horror scenario seems to be the fuzzy role of an element, mine is 
every new element. ;-)

I feel queasy, but as a sign of willing, I'm ready to bite the bullet. 
If you can't stand with <message> extent the model with <content> or <lab

But please, check again if you can't find a smarter solution like, 
changing message's the attribute 'errno' to 'id'. This will pay respect 
to different ways of using <message>

Uwe


PS.
> As said before, messages are not meant to be displayed to end-users at
> all - neither from the message element's textual content nor derived
> from an error id. Notifications of the sourced lending system are
>
> - either internal librarian-stuff, irrelevant to end-users
> - or specific kinds of textual strings, which can better be encoded
>     in explicit elements (for instance label)
Not really. In our application the messages should be encoded. But the 
end user messages in the OPACs (LBS3) of our librarys are generated with 
external logic and additional informations. For this reason there are to 
much possible variants to encode the properly.