search

airsalliance / airs-xml

Automatically exported from code.google.com/p/airs-xml
Creative Commons Zero v1.0 Universal
3 stars 2 forks source link

all types made top-level types #1

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
If all types are top-level types, they can be reused within the same
schema, or imported into another schema.

Original issue reported on code.google.com by eric.c.j...@gmail.com on 2 Feb 2010 at 6:01

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Can this be expanded so that the Agency, Site, ServiceSite (and Service if we 
can bring that into the schema) elements can have any of the other top-level 
element as a child? This would remove a lot of assumptions built into the 
schema about what can and cannot be in the Agency, Site and ServiceSite 
elements. 

For example, some clients want to put GeographicAreaServed information at the 
Site level, rather than the ServiceSite level. 

Anything that is prohibited by the AIRS standards should not be allowed (e.g. 
taxonomy assignments at the Site level), but otherwise it should be allowed in 
the schema. 

This might also illuminate new areas of the AIRS standards and style guide that 
should be better defined....e.g. perhaps GeographicAreaServed should not be 
allowed at the Site level - but that should first be incorporated into the AIRS 
standards and only then reflected in the AIRS XML Schema.

Original comment by bleeb...@gmail.com on 9 Dec 2011 at 6:39

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I like your idea of allowing GeographicAreaServed to be placed at different 
levels.  I think that's a different issue.  I think it could be generalized 
like this, but we'd have to look at specific examples of what that would allow, 
and if the various combinations actually made sense, in real terms.  I've 
created a new issue for this.

Original comment by e...@ejahn.net on 17 Feb 2012 at 3:06

GoogleCodeExporter commented 9 years ago 
voting was in favor of making this change in version 4.0

Original comment by e...@ejahn.net on 17 Feb 2012 at 3:10

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
This text from Indexing Using Target Population Terms
in the AIRS/INFO LINE Taxonomy by
Diane Gatto (United Way Services, Cleveland OH)
and Cathleen Kelly (LIFE LINE, Rochester NY)
 helped me: 

"Without the use of target populations, it would not be possible within
the Taxonomy to search the resource database for all services targeted
to people with AIDS/HIV, or those with cancer, or those who are
Hispanic. In addition, it would not be possible within the Taxonomy to
reduce long match lists of available resources to only the target
population you desire. Target populations can prove very useful, but
tremendous indexing discipline is required if they are to be helpful."

Original comment by e...@ejahn.net on 24 Feb 2012 at 8:26

GoogleCodeExporter commented 9 years ago 
implemented in 3.1, since removal of any ##other was also voted for, and they 
conflict.

Original comment by e...@ejahn.net on 22 Mar 2012 at 7:47