Repository (repo:) namespace under-specifies properties used by AEM repository-api; repo:id meaning is ambiguous

[cgoudie]

Summary

The repository (repo:) namespace — http://ns.adobe.com/adobecloud/core/1.0/ — is the canonical XDM home for storage/repository metadata, but its active definition (components/datatypes/external/repo/common.schema.json) currently defines only four properties:

• repo:name
• repo:path
• repo:createDate
• repo:modifyDate

Meanwhile, Adobe Experience Manager's repository API (the public Adobe I/O Repository API / AEM repository-api) emits and consumes a substantially larger set of repo: properties. Because XDM under-specifies the namespace, consumers cannot validate or discover these properties against the standard, and the same property name (repo:id) is being used with materially different meanings in different products with no authoritative definition to disambiguate.

This issue proposes to bring the repo: namespace in XDM up to date with the properties that are already in production use, and to clarify the wording for the properties whose meaning is currently ambiguous.

Gap: properties used by AEM repository-api but not defined in XDM

Grouped by concern. The four already in XDM are marked ✓.

Core resource metadata

Property	In XDM	Notes
repo:name	✓
repo:path	✓
repo:createDate	✓
repo:modifyDate	✓
repo:createdBy	✗	identity of the creator
repo:modifiedBy	✗	identity of the last modifier
repo:etag	✗	entity tag / opaque version token
repo:size	✗	size in bytes
repo:version	✗	version label
repo:assetId	✗	repository-scoped asset identifier (see note below)
repo:assetClass	✗	classification of the asset
repo:id	✗	unique identifier of an addressable repository entity (see note below)
repo:repositoryId	✗	identifier of the repository instance
repo:repositoryType	✗	type of the repository

Lifecycle / state

Property	In XDM	Notes
repo:state	✗	lifecycle state of the resource
repo:discardDate	✗	when the resource was discarded
repo:discardedBy	✗	who discarded it
repo:expires	✗	expiry timestamp
repo:lastPublishedTime	✗	last publication timestamp
repo:ancestors	✗	ancestor path chain

Access control / relations

Property	In XDM	Notes
repo:acl	✗	access control list
repo:relations	✗	related resources
repo:principal	✗	principal in an ACL entry
repo:privileges	✗	granted privileges
repo:inheritance	✗	ACL inheritance

Storage / transfer / discovery

Property	In XDM	Notes
repo:owner	✗	owner (object map)
repo:resource	✗	resource designator (object: repo:reltype, component_id, revision, etag)
repo:md5	✗	binary MD5 checksum
repo:blocksize	✗	block transfer size (integer)
repo:accelerated	✗	accelerated transfer flag (boolean)
repo:availableRegions	✗	regions where the repo is available (string array)
repo:environment	✗	repository environment

Dynamic Media (Scene7)

Property	In XDM	Notes
repo:scene7Domain, repo:scene7File, repo:scene7FileStatus, repo:scene7Folder, repo:scene7FontStyle, repo:scene7FontType, repo:scene7LastModified, repo:scene7Name, repo:scene7RTFName, repo:scene7Type	✗	Dynamic Media (Scene7) delivery metadata (all strings)

Property shapes were verified against the repository-api serialization code and confirmed against a live AEM as a Cloud Service instance. Notably, repo:principal serializes as either a string or an object ({@id, xdm:provider, @type}) depending on principal type, and repo:modifier uses the values GRANT/DENY.

Note: the conditional-request properties repo:if-match and repo:if-none-match are intentionally excluded from this proposal. They are operation preconditions supplied on a request (an ETag the operation is made conditional on, mirroring HTTP If-Match/If-None-Match), not descriptive metadata of the stored resource.

Several of these were historically modeled in XDM and currently sit in archived/external/repo/ (asset, directory, accesscontrolentry, accesscontrolpolicy, effectiveprivileges). This proposal effectively re-establishes and consolidates them under the active core/1.0 namespace.

repo:id is ambiguous and needs clarified wording

repo:id is currently used with three distinct meanings across Adobe products, and XDM's wording only describes one of them:

Source	Example value	Meaning
XDM active (extensible, decisioning)	urn:aaid:a:b:…	"unique identifier to reference the asset in a content repository"
AEM repository-api	urn:aaid:sc:…	deprecated alias of repo:assetId (asset identifier)
Collaboration/annotation schemas	urn:uuid:…@AdobeID	a person / principal identifier

The core problem: repo:id is fundamentally the unique identifier of an addressable entity within a repository — and the type of that entity depends on context (an asset, a directory, or a person/principal). XDM's current description hard-codes "asset," which is too narrow and actively misleads automated consumers into assuming repo:id always denotes an asset.

Proposed clarification:

• Define repo:id generically as "the unique identifier of an addressable entity within a repository," not specifically an asset.
• Define repo:assetId as the asset-scoped identifier, and document that repo:id is the older/generic property which AEM repository-api now treats as a deprecated alias of repo:assetId in asset contexts.
• Make the relationship between repo:id and repo:assetId explicit so consumers (and code-generation/agent tooling) stop conflating them.

Proposal

1. Extend components/datatypes/external/repo/common.schema.json (core/1.0) to define the full set of repo: properties above, with clear, product-neutral descriptions.
2. Clarify repo:id wording and its relationship to repo:assetId.
3. Update common.example.1.json, regenerate docs/reference, and add a CHANGELOG.md entry.

A pull request implementing this will follow and reference this issue.