Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "XML File Context Provider"
| Line 6: | Line 6: | ||
# The getSchema() needs to be updated to follow the latest ontology. | # The getSchema() needs to be updated to follow the latest ontology. | ||
| − | # The format of the identity data should more closely follow the Higgins | + | # The format of the identity data should more closely follow the Higgins data model and, since we control it, we can structure the XML however we want. Besides, I don't like the file format as it stands anyway. In addition, if we structure it right, we won't have to do any mapping of types from the XML to Higgins, it can just BE what we expect in Higgins or even the consuming application (ie. CardSpace claims). At any rate, currently, that's not the case. |
| − | data model and, since we control it, we can structure the XML however we | + | # Respond to registry and configuration model changes when they are completed. #2 should be done in conjunction w/ this. |
| − | want. Besides, I don't like the file format as it stands anyway. In | + | |
| − | addition, if we structure it right, we won't have to do any mapping of | + | |
| − | types from the XML to Higgins, it can just BE what we expect in Higgins or | + | |
| − | even the consuming application (ie. CardSpace claims). At any rate, | + | |
| − | currently, that's not the case. | + | |
| − | # Respond to registry and configuration model changes when they are | + | |
| − | + | ||
# Allow updates through IdAS APIs. | # Allow updates through IdAS APIs. | ||
Revision as of 14:25, 7 March 2007
Work in progress ...
Configuration Info
XML File CP TODO:
- The getSchema() needs to be updated to follow the latest ontology.
- The format of the identity data should more closely follow the Higgins data model and, since we control it, we can structure the XML however we want. Besides, I don't like the file format as it stands anyway. In addition, if we structure it right, we won't have to do any mapping of types from the XML to Higgins, it can just BE what we expect in Higgins or even the consuming application (ie. CardSpace claims). At any rate, currently, that's not the case.
- Respond to registry and configuration model changes when they are completed. #2 should be done in conjunction w/ this.
- Allow updates through IdAS APIs.