Expose constructors

[ocramz]

At least two people in the past week mentioned use cases for constructing XML :

• OpenSearch for Flora.PM Implement OpenSearch flora-pm/flora-server#127 (cc @tchoutri)
• diffing SVG trees in chart-svg chart-svg surgery tonyday567/chart-svg#27 (cc @tonyday567)

[ocramz]

I guess exposing lenses as in #57 would be a more general fix

[tchoutri]

@ocramz Thank you for opening this! Personally I think that having integrated builders into xeno and optional lens bindings works best, as it is good form to stick with 1 lens library in a codebase. It would be hard to tell people to bring in a whole other ecosystem of lens libraries just for one dependency.

[tonyday567]

for my use case, I was looking for a representation of something like:

data NodeUnpacked = NodeUnpacked { name :: ByteString, attributes :: [(ByteString, ByteString)], contents :: [ContentUnpacked] }

-- | Content of a node.
data ContentUnpacked
  = ElementUnpacked {-# UNPACK #-}!NodeUnpacked
  | TextUnpacked {-# UNPACK #-}!ByteString
  | CDataUnpacked {-# UNPACK #-}!ByteString
  deriving (Eq, Show, Data, Typeable)

I've never really dug into xeno, though, and I don't know if this type of unpacked representation is compatible with the objectives of this library.

If it is, then my concept of a XML constructor is an iso for switching between Node and NodeUnpacked.