Invalid output on incorrect call

[fehmud]

Hello,

the following incorrect call (notice that the value of :MULTIPLE is missing):

(<:select :multiple
             (<:option :value "volvo")
             (<:option :value "saab")
             (<:option :value "opel")
             (<:option :value "audi"))

SEXML silently generates this invalid XML (see the first line):

<select multiple="<option value=&quot;volvo"></option>">
   <option value="saab"></option>
   <option value="opel"></option>
   <option value="audi"></option>
</select>

At least, I think that SEXML should generate valid XML anyway (albeit not what the user intended). However, SEXML could raise an error on calls where the values of attributes are not of the expected types: strings, numbers, booleans... I don't know whether it would make sense to accept characters.

Thanks for your attention.

[madnificent]

SEXML is designed to operate in a functional manner.

This effectively means that the #'<:select call has no knowledge about the structure of the #<:option call, only about the result. We could perform a regex check on the keyword value of multiple, but that could be a rather big performance hit. If we would do this, then we would probably need to fetch it from the DTD. I have not implemented the parsing for such a thing so far.

I don't feel like implementing this at the moment. Not because I'm against it, but I don't need it and I don't feel like doing it. Good pull requests are always appreciated.

Cfr it only escaping the first quoted value in the string: Yes that's wrong. I've just pushed out a fix for it.

[fehmud]

While I agree that SEXML should ignore the semantics of what it generates, generating incorrect XML doesn't seem right. Instead of a regexp check, SEXML could quote values instead of passing them through format. Composite types should be rejected because they don't make sense in XML. Actually, do value types other than strings make sense for a XML library? Users with special needs could always hook a custom outputter like you said here.

The package XMLS -- available via Quicklisp -- exports a TOXML function that quotes strings (and other scalar values). TOXML chokes on lists and, as said, this is a feature.

Quoting strings will be slower than string concatenation, so it could be made optional for users that seek raw speed. But -- again -- users with special needs could rely on a different outputter.

Thanks for your attention.

[madnificent]

As it stands, SEXML allows lists to be placed anywhere. When you supply a list, we assume it should be concatenated. In the functional setting this means that we either receive a list or a string, both of which will boil down to a string input. This seems to work well in practice.

Coming back to your question though: in the example you supply, you don't supply a list to the :multiple keyword. The first #'option call is sent to it, the other option tags are used for the body.

As of the last commit to SEXML, all quote (") symbols will be replaced by " instead of only the first one. I believe this should make the result valid XML. I somewhat feel that this is enough for a standard implementation. That being said, I place low values on a standard implementation.

Keep in mind that everyone seems to want something different from an XML/HTML generator. I'm not sure what you would prefer, but I assume you'd want an outputter which throws a warning when the output is not what you'd want it to be. We can build such a thing within SEXML (as a framework), but there is currently no input of what the value for an attribute should be. I believe that is where the bulk of the work lies if that's what you'd want: having a DTD which contains such information and parsing it. For what it's worth: the specification needn't be in a DTD, if you want to supply a different format, that would be supported too. Taking one more step back, I believe the main thing is to write down how you would want SEXML to behave and then see how we can hook everything together (and which extensions we'll need to be build) to make it work that way. I'm eager to hear about your preferences.

[fehmud]

Thanks for your detailed explanation.

I have realized that quoting attribute values doesn't make sense at all. Therefore, I agree with your fix. In regard to accepting lists... I don't know XML well and I don't know what to say about it. Would you please provide an example of their usefulness?

What instead should always be quoted -- following XML rules -- is text between tags. For instance, this:

(<:html
 (<:head (<:title "titolo"))
 (<:body
  "</body>"))

returns:

"<!DOCTYPE HTML >
<html><head><title>titolo</title></head><body></body></body></html>"

while instead should return:

"<!DOCTYPE HTML >
<html><head><title>titolo</title></head><body>&lt;/body&gt;</body></html>"

Again, XMLS:TOXML would serve this purpose.

I understand that you are developing this package for your own use and I am already grateful that you are sharing it but, please, if you are not interested to a standard implementation, alert users in the README. Your package is featured in the "Lisp Web Tales" book, therefore novices are expected.

Regarding what I would want from an outputter, the sketch that you provided elsewhere is more than enough for my needs now. I am an HTML5 novice, and I would rather gain more experience before designing a library for it.

Cheers.

[madnificent]

Ah, I understand what you are getting at. That is indeed a possible issue. I chose to do it this way merely because I wanted to be able to insert raw HTML in case SEXML didn't fit the purpose. It's been handy so far, but I do understand that it may be confusing to some. Personally, I find it the element of least surprise.

If we would like to solve this, we would need to introduce the concept of an "html-safe" string. An html-safe string is a string which has been escaped already. Any string that comes into SEXML's realm would need to be coerced into an html-safe string before it could be printed.

As of now, there is nothing separated to handle the printing of a single string. We could extend SEXML with specific functionality on how to print a string. This functionality could be overridden in a layer which handles how strings should be printed in a separate contrib. We could name the contrib html-safe. Other contribs would likely need to be extended. Should we go ahead with this?

Regarding the construction of a new html library: I built SEXML to be flexible enough so that it encompasses the needs of most users if configured correctly. The general idea is that users are able to configure their XML outputting library by enabling layers (with each layer representing a feature). This should mean that if SEXML is extended with enough features, that far less code would need to be written to support each user's preference.

[fehmud]

Hi, I am leaving for a trip, hence I won't be able to contribute to this discussion for a while. I didn't want you to think that I had disappeared. Cheers.