- Can I use survos/providence-bundle in a Laravel application?
- No, not directly. It is a Symfony bundle that depends on Symfony's bundle, dependency injection container, config tree, and event dispatcher contracts, while Laravel's container and package discovery work differently. Only the domain logic for reading PAWtC profiles is portable, and you would need to extract or reimplement the wiring.
- How do I install and register survos/providence-bundle?
- Install it with Composer and register the bundle in config/bundles.php inside a Symfony application. The repository has no README quickstart or visible release tags, so expect to pin a commit and work out service configuration from the bundle source. There are no documented usage examples to follow.
- What is a CollectiveAccess Providence profile and why would I parse one?
- A Providence profile is a PAWtC XML document that defines elements, attribute types, relationships, and UI for a CollectiveAccess installation. Parsing it lets an application reason about a museum or archive metadata schema, for example to map fields or validate data. That schema interpretation is the durable value here, not the bundle plumbing.
- Which Symfony and PHP versions does this bundle support?
- The evaluation suggests Symfony 6 or 7 with Doctrine and PHP 8.x as the native target, but no release history or documented constraints are visible. You must inspect composer.json to confirm constraints and check whether they drag you onto end-of-life versions. There is also no versioning contract tied to CollectiveAccess profile semantics.
- Is survos/providence-bundle actively maintained and safe to depend on?
- It has zero stars, zero dependents, and no visible release tags, and it comes from a single-maintainer ecosystem. That implies high bus-factor and abandonment risk, so treat it as source material rather than a dependency. Pin a commit and be prepared to fork if you rely on it.
- How do I test that the bundle correctly maps a real Providence profile?
- Obtain a representative PAWtC profile from the target institution along with its CollectiveAccess version, then run it through the bundle. There are no tests visible from outside, so you must build your own verification harness. Budget a multi-day spike because profile-to-entity mapping failures can silently drop attributes.
- What are the production risks of parsing Providence XML profiles?
- XML parsing of externally supplied profiles exposes you to XXE and billion-laughs attacks unless libxml configuration is audited and hardened. Silent data loss is also a high risk because mapping failures tend to drop attributes quietly instead of raising errors. Schema drift across CollectiveAccess versions adds further risk.
- What alternatives exist to using this bundle for CollectiveAccess integration?
- You can parse PAWtC XML against the published XSD yourself, call the CollectiveAccess Providence web services API, or read from the CA database. The bundle is one of four options and the least supported. Choose based on whether the real requirement is interoperating with a live CA instance or consuming a metadata profile as a schema.
- Is the bundle license compatible with my project, and is the provenance clean?
- The bundle is MIT-licensed, but CollectiveAccess itself is GPL-3.0, so license provenance needs checking before you embed any derived code. Confirm whether any of the schema-handling code originated in CollectiveAccess. Do this before adoption, not after.
- Should I use this bundle as a reference implementation or a Composer dependency?
- Use it as a reference implementation for schema handling, not as a dependency. Budget a three-to-five day timeboxed spike with a pre-agreed fallback such as your own parser or the CA API. It has effectively no documentation, examples, or downstream users to learn from.