1) I've brought this up with with AIRS folks, and it's currently not
fully resolved yet in my opinion, but tSiteService is not yet an
importable type, because it contains an <any/> tag at the end. The
<any/> tag is used by the AIRS Schema much like the erstwhile "Custom"
tags were in HUD HMIS 2.7 to provide an extension mechanism (albeit
incapable of being validated by the schema). I've asked the AIRS group
to remove <any/>, from the tSiteService type at least, so I can import
tSiteService. We removed <any/> tags from the HMIS Schema, since it's
not a good way to provide extensibility, since importing/including is
better since it can be validated. However, I don't want this discussion
to delay release of the 2.8 HMIS Schema, so I'll likely have to just cut
and paste tSiteService into the HMIS Schema for now (and I apologize to
the designers of XML Schema for this architectural transgression).
2) I may be wrong about this due to my limited understanding of the AIRS
Schema, but the HUD HMIS ProgramParentID doesn't really line up directly
with anything in the AIRS Schema. They have hierarchical Agencies,
Sites, and Site Services (aka "program" in the HMIS world). A
SiteService can't be the parent of another SiteService in AIRS, only a
Site can be a parent. So ... I'm thinking we should remove
ProgramParentID from the HUD Schema and replace it with a ParentSite
element. Then if people want to transmit full info about that
ParentSite or the Agency even further up the hierarchy, they can just
send AIRS XML to express those relationships.
3) Would there be an objection to renaming "Program" in the HMIS Schema
to "SiteService" to avoid ambiguity?
Thoughts?
--
Eric Jahn
Alexandria Consulting LLC
3126 8th Ave. N
St. Petersburg, FL 33713
941.321.1466