[DDI-SRG] Bug 92 - References not all in reusable namespace

[Pascal Heus]

I don't have much light to shed on this, just found it confusing to have 
some references in reusable and others that are not. Makes life more 
complicated as you need to remember which is where. Aggregating in 
reusable is just a suggestion though.
*P

Wendy Thomas wrote:
> Yes, hopefully Pascal can. I should note that in many cases the individual 
> reference elements are extentions of the basetype r:Reference as opposed 
> to being simply type="r:Reference". I don't know anything about the 
> processing implications and I'm sure that Arofan and J will have feelings 
> about integrity of the XML structure. Clearly this will be on the agenda 
> tomorrow.
>
> Everyone try to wrap your heads around this one.
>
> Wendy
>
>
>
> On Wed, 23 Jan 2008, Joachim Wackerow wrote:
>
>   
>> I think I asked for a unique reference type and reference element in
>> reusable which can be easily processed and identified as a reference
>> because the element is always the same (it would be contained in the
>> element of the specific module). But my (bad) memory says I had not
>> really success with that proposal.
>>
>> Bug 92 seems to head for something other which I don't really understand
>>  based on the provided information.
>>
>> Again (from my last email):
>>     
>>>> Consistency is important.
>>>> But in which namespace should stay the reference elements, in the
>>>> specific module or in reusable? What is the reasoning for either
>>>> solution?
>>>>         
>> Now all reference elements (not types) seem to be in the specific
>> module, not in reusable.
>> Perhaps Pascal can shed some light on this, he filed the bug.
>>
>> Achim
>>
>> Wendy Thomas wrote:
>>     
>>> Achim,
>>> Here are some spreadsheets providing the location of all r:Reference
>>> type elements and Reference elements by location. There are a number of
>>> cases where something is declared in say logical and used also in
>>> datacollection due to the way we have used the category and coding
>>> schemes. However, I echo you question of the purpose of putting ALL
>>> reference type elements in resuable.
>>>
>>> Wendy
>>>
>>>
>>> On Wed, 23 Jan 2008, Joachim Wackerow wrote:
>>>
>>>       
>>>> What is really the reason for having the reference elements in
>>>> reusable namespace: consistency or processing issues? I'm not sure if
>>>> I understand it right.
>>>>
>>>> Bug 92 says:
>>>> "CategoryRerefence in a CodeScheme is in the logical product namespace
>>>> but CodeSchemeReference in a variable CodeRepresentation is in the
>>>> reusable namespace"
>>>>
>>>> This doesn't seem the case looking at the logical schema (currently
>>>> both elements are in the logical namespace):
>>>>
>>>> logical.xsd:
>>>>
>>>> <xs:element name="CategoryReference" type="r:ReferenceType">
>>>> </xs:element>
>>>>
>>>>
>>>> <xs:element name="CodeSchemeReference" type="CodeSchemeReferenceType">
>>>> </xs:element>
>>>> <xs:complexType name="CodeSchemeReferenceType">
>>>>  <xs:complexContent>
>>>>    <xs:extension base="r:ReferenceType">
>>>>      <xs:sequence>
>>>>        <xs:group ref="CodeSubsetInfo"/>
>>>>      </xs:sequence>
>>>>    </xs:extension>
>>>>  </xs:complexContent>
>>>> </xs:complexType>
>>>>
>>>>
>>>> The reference element in group seems to be unnecessary as all the
>>>> reference elements can be directly type of r:ReferenceType.
>>>>
>>>> group.xsd:
>>>>
>>>> <xs:element name="Reference" type="r:ReferenceType">
>>>> </xs:element>
>>>>
>>>>
>>>> Consistency is important.
>>>> But in which namespace should stay the reference elements, in the
>>>> specific module or in reusable? What is the reasoning for either
>>>> solution?
>>>>
>>>> Did I miss something?
>>>>
>>>> Achim
>>>>
>>>> Wendy Thomas wrote:
>>>>         
>>>>> so it looks like from the bug (and my action notes) that this is only
>>>>> an issue in Group. I think consistancy important so do it. Does it
>>>>> require a change beyond the instance noted in the bug?
>>>>>
>>>>> wendy
>>>>>
>>>>> On Tue, 22 Jan 2008, arofan.gregory wrote:
>>>>>
>>>>>           
>>>>>> Folks:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pascal raised an issue which wants - for consistencies' sake - to have
>>>>>> references (that is, the elements, not just the type declaration)
>>>>>> all be in
>>>>>> the reusable namespace. I'm OK with this - what do other people think?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Arofan
>>>>>>
>>>>>>
>>>>>>             
>>>>> Wendy L. Thomas                          Phone: +1 612.624.4389
>>>>> Data Access Core Director         Fax:   +1 612.626.8375
>>>>> Minnesota Population Center              Email: wlt at pop.umn.edu
>>>>> University of Minnesota
>>>>> 50 Willey Hall
>>>>> 225 19th Avenue South
>>>>> Minneapolis, MN 55455
>>>>> _______________________________________________
>>>>> DDI-SRG mailing list
>>>>> DDI-SRG at icpsr.umich.edu
>>>>> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>>>>>           
>>> Wendy L. Thomas                          Phone: +1 612.624.4389
>>> Data Access Core Director         Fax:   +1 612.626.8375
>>> Minnesota Population Center              Email: wlt at pop.umn.edu
>>> University of Minnesota
>>> 50 Willey Hall
>>> 225 19th Avenue South
>>> Minneapolis, MN 55455
>>>       
>> -- 
>> GESIS - German Social Science Infrastructure Services
>> http://www.gesis.org/en/
>> _______________________________________________
>> DDI-SRG mailing list
>> DDI-SRG at icpsr.umich.edu
>> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>>
>>     
>
> Wendy L. Thomas                          Phone: +1 612.624.4389
> Data Access Core Director		 Fax:   +1 612.626.8375
> Minnesota Population Center              Email: wlt at pop.umn.edu
> University of Minnesota
> 50 Willey Hall
> 225 19th Avenue South
> Minneapolis, MN 55455
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.icpsr.umich.edu/pipermail/ddi-srg/attachments/20080123/8cae31b5/attachment.html