The library (currently) named SwiftXML which had been initiated by me and which can be used to access and transform XML documents in Swift applications recently gained some traction (19 stars now 
, a good part of them in recent days). Moreover, I will probably give a little talk about it as FOSDEM 2025 at February 1st or 2nd.
So I think this is a good time (or at least something that should not wait any longer) to plan to publish this library again under a new URL with the following goals:
- I would like to decouple this library to some part from me as a person, the idea is to have a repository URL that only involves the library's name. There could also be an according *.org website.
- This would come with a strong commitment for changes not to break the API without a new major version, and also more intensive testing (see more on this below).
- The API could benefit from some changes regardings names of methods etc. Maybe some of the current users have some suggestions e.g. for the changing of names? Changes at a later point would be more difficult.
- Maybe there could also be better name for the library?
- Maybe already including the reading from streams (see the list at the end), to avoid an early possibly API breaking change.
So anyone already using this library, please look out for any according announcements at the start of the repo's README.
I would also plan to add the following other libraries under the same "organisation" so to speak:
- SwiftXMLParser and SwiftXMLInterfaces which realize the parsing (there are reason why no traditional XML parser was used).
- AutoreleasepoolShim but which might not be necessary any more with the new Foundation.
- LoopsOnOptionals: Looping over optionals (cf. the repo's README for an explanation) is kind of a controversial issue and as such never made it into the Swift language, but it comes in handy for the XML library, so you can add it by inlcuding this little package.
- SwiftWorkflow (and WorkflowUtilitiesForSwiftXML) which will be renamed to "Pipeline" and which is a way to organise e.g. complex transformations of XML content (but also for other applications). Before that, this library should be decoupled from its own logging implementations to make it usable with other logging mechanisms.
Of course, I would also invite people to make suggestions or collaborate.
The reasons why I was holding back this new publishing for a while now are the following:
- The unit tests are not "complete". The library is nevertheless quite "trustworthy", because we run several complex applications which use this library extensively, and they are also being tested. But of course the unit tests should be more complete.
- I should add more comments to the code, at one side because the documentation produced by DocC should be better, and also there should be more explanations in the code about how things work.
There are also some other things that one would like to have:
- Not importing the full
Foundation. - Not using AutoreleasepoolShim any more?
- Parsing is currently only implemented for whole texts or
data, but not for streams. This would not be a big change (and maybe no API breaking change), but is not done yet. - You cannot process an XML document concurrently. This is intentionally (I will address this in my talk), but there is the idea to be able to have other XML document instances within an XML document instance, so that you could transforms those documents concurrently. But I am not sure if this is needed and worth the then added complexity.
- Last but not least: It is planned to have a validation library to be usable 1) while parsing, and 2) for XML trees of this XML library (the second part is easy once you have the first part because you can create the according parsing events from an XML tree). The idea is to be able to validate against W3C schemas, but maybe using some of the techniques used by Relax NG (the Oxygen XML editor actually used or still uses this method).
So thanks to anyone using it and being nice about it not being in a "final" state yet.