Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DPG] Python emitter should respect and generate xml metadata on all models #2922

Open
catalinaperalta opened this issue Nov 15, 2024 · 1 comment
Assignees

Comments

@catalinaperalta
Copy link
Member

I noticed that the typespec-python emitter doesn't always add xml metadata on generated models. Example of models that arent getting xml metadata on them: ListBlobsFlatSegmentResponse, BlobHierarchyListSegment, BlobItemInternal, etc). Seems we're currently only generating xml metadata if that model is used in an operation with application/xml. However, if a service team has defined a model with xml data on it, we should respect that and always generate the model with xml rest metadata to ensure proper serialization/deserialization whenever that model is being used.

Additional context, some services define models used for convenience that arent specifically linked to any operations. Regardless of where the model is used, we should add any relevant xml metadata on them if they were specified in the tsp.

Example spec using xml: https://github.com/Azure/azure-rest-api-specs/tree/feature/blob-tsp/specification/storage/Microsoft.BlobStorage

@catalinaperalta
Copy link
Member Author

catalinaperalta commented Nov 15, 2024

Related bug, @xml.name should be respect for every property that has it. Since we arent generating some models with their xml metadata, they're getting incorrect rest field names. Example of bug:

next_marker: Optional[str] = rest_field(name="nextMarker")

The casing of the next_marker property in xml is NextMarker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants