[DDI-SRG] DDI 1/2.x DTD / XSchema discrepency

Mark Diggory mdiggory at MIT.EDU
Mon Jul 14 11:04:25 EDT 2008


Ok, I have to correct myself, I do see the discrepancy now and I did  
do these changes 3 years ago and they were migrated along with  
everything else to the SVN repository...

http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/

in the following the change exists.

http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-02-1.dtd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-02.dtd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-2-2.dtd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-3.dtd?view=log

In the following the change does not exist and will cause the  
discrepancy that Pascal outlines.

http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-02-1.xsd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-02.xsd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-2-2.xsd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/1/ 
schema/Version1-3.xsd?view=log

In the following, the schema and dtd do properly match.

http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/2/ 
schema/Version2-0.dtd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/2/ 
schema/Version2-0.xsd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/2/ 
schema/Version2-1.dtd?view=log
http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/DDI-TIC/2/ 
schema/Version2-1.xsd?view=log

However, it is always the case that these are working copies and not  
the official versions that the community uses are located under:

http://www.icpsr.umich.edu/DDI/Version1-3.dtd
http://www.icpsr.umich.edu/DDI/Version1-2-2.dtd
http://www.icpsr.umich.edu/DDI/Version1-02-1.dtd
http://www.icpsr.umich.edu/DDI/Version1-02.dtd

And these are the files that would be used for validation by the  
community, they do not contain the above changes to add xml:lang.   
Thus this issue is only exposed to those who use the copies from S.F.  
cvs/svn repository.

Now, reflecting on these changes that I did do back then, its unclear  
to me why I did not complete the changes to the xsd as well.  I will  
say that if the original xml:lang issue were tabled today, I may have  
been less likely to support it based on the comments in my previous  
email (even though it would be sorely needed, it would break  
compatibility).  Since these have never been "fully sanctioned" in  
the DDI Community by actually replacing the originals found at the  
website URL's (its sad thats what would be considered  
"sanctioned"),then there is the possibility that xml:lang could be  
removed from the svn dtd's and not exposed to the community as a fix.

So, thats the history, given I no longer maintain any code dependent  
on DDI schema's or dtds, I do not have a vested interest in this  
support, so either solution seems fine with me ATM.

Sincerely,
Mark


On Jul 14, 2008, at 7:35 AM, Wendy Thomas wrote:

> Mark is correct, this is the one were the error was originally made.
>
> Wendy
>
>
> On Mon, 14 Jul 2008, Mark Diggory wrote:
>
>> Hello everyone,
>>
>> I will comment on these since I managed the bug concerning them a  
>> few years ago.
>>
>> 1.) These are not broken and do not contain any bugs from my  
>> testing. Pascal, the DTD and XSD you reference "does not" have a  
>> xml:lang attached to its codebook element
>>
>>> <!--temporary parameter  
>>> entities                                      -->
>>> <!ENTITY % a.global 'ID ID #IMPLIED
>>>            xml-lang NMTOKEN #IMPLIED
>>>            source (archive|producer)  
>>> "producer"'                        >
>>> <!-- codeBook version attribute [for application  
>>> processing]          -->
>>> <!ENTITY % a.version 'version     CDATA     #FIXED      
>>> "1.2.2"'          >
>>> <!--  
>>> CodeBook.DTD                                                     -->
>>> <!-- 0.0 TOP  
>>> LEVEL                                                    -->
>>> <!--  
>>> =============                                                    -->
>>> <!--                                                                 
>>>   -->
>>> <!ELEMENT codeBook     (docDscr*
>>>              , stdyDscr+
>>>              , fileDscr*
>>>              , dataDscr*
>>>              ,  
>>> otherMat*)                                               >
>>> <!ATTLIST codeBook %a.global;
>>>                    % 
>>> a.version;                                          >
>>
>>
>>
>> 2.) Backwards compatibility requires that now that xml-lang is  
>> there in all documents that it be retained as the way one refers  
>> to the language so that older tools do not break by the allianced  
>> making changes to the DTD and XSD.
>>
>> 3.) It will also not be forwards compatible to introduce a change  
>> where xml:lang is now available in those versions. specifically,  
>> if you add this in to 1.2.2 and now tools start generating 1.2.2 
>> +xml:lang, older tools that were capable of handling 1.2.2 will  
>> fail to be able to process the 1.2.2+xml:lang content they've  
>> stated they are compliant with, thus there's not much reason for  
>> new tools to be generating 1.2.2+xml:lang if it cannot be consumed  
>> by older tools.
>>
>> My recollection was that we decided not to change anything earlier  
>> than the current 2.1 version of the schema and dtd that we were  
>> doing maintenance work on.  And it still stands, I would not  
>> recommend making such a change to earlier versions of the dtd/xsd  
>> for which content exists in the wild.
>>
>>> Sanda:
>>> Thanks for the fedback. I'll be traveling in a few hours...  
>>> should be able to take care of this next week and commit the  
>>> changes to CVS. Will keep you posted so it can then be reflected  
>>> on the web site.
>>> best
>>> *P
>>
>> Also note that last year the S.F. site converted from CVS to SVN  
>> with an announcement to the community. I still see references to  
>> the Sourceforge CVS in the DDI documentation posted on the website  
>> and if you make changes in the old CVS they will not be reflected  
>> in the SVN repository that is now used.
>>
>>> Everyone,
>>> I wanted to announce that we've moved from cvs to svn on the  
>>> Sourceforge project and that this may effect your website links  
>>> that will need correcting.  The old CVS service is still readable  
>>> but is not advertised on the Sourceforge site and not writable by  
>>> any developers anymore.  All changes will now be maintained in  
>>> the SVN repository Here are the new links and details on how to  
>>> access those services:
>>> How to access the SVN repository:
>>> http://sourceforge.net/svn/?group_id=100852
>>> Using ViewVC to access the repository (giving online diff  
>>> capabilities);
>>> http://ddi-alliance.svn.sourceforge.net/viewvc/ddi-alliance/
>>> If you wish to directly access the repository and you can then  
>>> access the most recent copy of a file, for instance
>>> http://ddi-alliance.svn.sourceforge.net/svnroot/ddi-alliance/DDI- 
>>> TIC/2/schema/Version2-1.xsd
>>> Please work to remove any references to the older CVS repository  
>>> from your websites.
>>
>> I might recommend that the community/web-site developers start  
>> using PURL to reference important documents in the site to reduce  
>> breakage cause by changes in support behind the scenes.
>>
>> Cheers,
>> Mark
>>
>>
>> On Jul 14, 2008, at 7:01 AM, Sanda Ionescu wrote:
>>
>>> Pascal,
>>> I think you can just go ahead and make the change - no need to  
>>> file a bug.
>>> Both xml-lang and xml:lang should be enabled for all versions 1  
>>> through 2.1 (although historically the change has only been  
>>> brought in version 2.1 )
>>> At some point somebody just made a typo in the DTD and as a quick  
>>> and easy fix we decided to enable both variants to avoid getting  
>>> invalid documents, or having to go back and look for instances  
>>> that might have been invalid. This change was filed as a bug at  
>>> the time, and approved.
>>> The schemas were just not correctly generated. That's why there  
>>> are discrepancies. We found many errors in those schemas and have  
>>> consistently been advising people to always refer to the DTDs as  
>>> the authoritative files.
>>> Sanda.
>>> -----Original Message-----
>>> From: Pascal Heus [mailto:pascal.heus at gmail.com]
>>> Sent: Mon 7/14/2008 8:39 AM
>>> To: DDI Structural Reform Working Group.; Mary Vardigan; Sanda  
>>> Ionescu
>>> Subject: DDI 1/2.x DTD / XSchema discrepency
>>> All:
>>> I recently noticed that the DTD and XSchema of the DDI 1.2.2 and 1.3
>>> specifications published under the official URL have a small
>>> discrepency:  in the DTD, the <codeBook> element definition   
>>> contains
>>> both and an xml-lang and an xml:lang attributes. This however is not
>>> carried over in the XSchema definition where the xml:lang does not
>>> appear. See for example:
>>> http://www.icpsr.umich.edu/DDI/Version1-2-2.dtd
>>> http://www.icpsr.umich.edu/DDI/Version1-2-2.xsd
>>> This actually caused the DDI produced by the latest version of the
>>> Nesstar Publisher (not yet released) to produce DDI-XML that did not
>>> properly validate (though being correct). I have notified the  
>>> developers
>>> and they have switched to the xml-lang attribute. This is however
>>> something we may want to correct in the published schemas.
>>> Also checked 1.02 and in that one both xml-lang and xml:lang are  
>>> missing
>>> from the schema For 1.01 and 1.0, only the xml:lang exists in the  
>>> DTD
>>> and is missing from the schemas.
>>> The 2.0 and 2.1 xsd files do not have this problem.
>>> How should we proceed to have these issues fixed in both CVS and on
>>> under the official http://www.icpsr.umich.edu/DDI/* URL's? Can we  
>>> simply
>>> make the change or do we need to file an official bug?
>>> best
>>> *P
>>> _______________________________________________
>>> DDI-SRG mailing list
>>> DDI-SRG at icpsr.umich.edu
>>> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>>
>>
>>
>> ~~~~~~~~~~~~~
>> Mark R. Diggory - DSpace Developer and Systems Manager
>> MIT Libraries, Systems and Technology Services
>> Massachusetts Institute of Technology
>> Home Page: http://purl.org/net/mdiggory/homepage
>>
>>
>>
>>
>>
>
> 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



More information about the DDI-SRG mailing list