[Exist-development] Fwd: [Exist-commits] SF.net SVN: exist:[13631] trunk/eXist/webapp/biblio/mods

[Jens Ø. P. <oe...@gm...>]

Forgot to mail the list.

Begin forwarded message:

> From: Joe Wicentowski <jo...@gm...>
> Date: January 28, 2011 5:17:02 PM GMT+01:00
> To: Jens Østergaard Petersen <oe...@gm...>
> Subject: Re: [Exist-commits] SF.net SVN: exist:[13631] trunk/eXist/webapp/biblio/mods
> 
> Hi Jens,
> 
> Thanks for your reply!  I think it'd be helpful for the others in the
> exist-development list to see this - I think you only sent it to me.
> Could you send it to the list too?
> 
> Have a good weekend too!
> Joe
> 
> 
> 2011/1/28 Jens Østergaard Petersen <oe...@gm...>:
>> 
>> On Jan 28, 2011, at 3:01 PM, Joe Wicentowski wrote:
>> 
>>> Hi folks,
>>> 
>>> I've noticed that some commits of XML files, such as Jens' below, come
>>> as a single, looooong line with no line breaks.  This makes it
>>> impossible to spot what changed in the commit, and I imagine it's not
>>> very efficient from an SVN perspective in which only "deltas" are
>>> stored.
>>> 
>>> I suspect this is caused by eXist's WebDAV or Java admin client not
>>> indenting during serialization.  Jens - which method are you using to
>>> get files out of eXist and into your SVN working directory?
>> 
>> I export from db via Java Admin Client, copy to webapp folder (manually!), commit via oXygen SVN Client.
>> 
>>> Am I
>>> right that the lack of indentation is unintended, Jens?
>> 
>> Yeah, sure. After export via Java Admin Client, most line-breaks (sometimes all) have been stripped and this often causes oXygen to choke. I could (manually) indent the documents, I guess, but it would be nicer to have the Admin Client maintain the line breaks.
>> 
>>> Are there steps we could recommend Jens to follow to prevent this
>>> phenomenon from occurring?
>> 
>> Thanks for bringing this up, Joe.
>> 
>> Have a nice weekend!
>> 
>> Jens
>> 
>>> 
>>> Thanks,
>>> Joe
>>> 
>>>> -<code-table><code-table-name>date-encoding-code</code-table-name><status>finished</status><form>closed</form><basis>http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html</basis><description/><notes/><items><item><label>(none selected)</label><value/></item><item><label>w3cdtf</label><value>w3cdtf</value><description>This value is used for the profile of ISO 8601 that specifies the following date pattern: YYYY-MM-DD.</description></item><item><label>iso8601</label><value>iso8601</value><description>This value is used for formatted dates allowed in ISO 8601 which use the alternative described as "basic" rather than "extended". This alternative specified in the standard uses the following date pattern: YYYYMMDD (hours, minutes, seconds may also be added). It is also used for other encodings specified in ISO 8601, e.g. date ranges, which are in the form of YYYY/YYYY (in which case start and end portions are not parsed). The ISO 8601 basic expression has been used widely in MARC 21 date elements.</description></item><item><label>marc</label><value>marc</value><description>This value is used only for dates coded according to MARC 21 rules in field 008/07-14 for dates of publication/issuance. Thus, this would only apply to the attribute in dateIssued. Examples include: 19uu (a MARC convention to show unknown digits in a date), 9999 (a MARC convention showing that the end date has not occurred or is not known).</description></item></items></code-table>
>>>> \ No newline at end of file
>>>> +<code-table><code-table-name>date-encoding-code</code-table-name><status>finished</status><form>closed</form><basis>http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html</basis><description/><notes/><items><item><label>(none selected)</label><value/></item><item><label>YYYY-MM-DD</label><value>w3cdtf</value><description>This value is used for the profile of ISO 8601 that specifies the following date pattern: YYYY-MM-DD.</description></item><item><label>iso8601</label><value>iso8601</value><description>This value is used for formatted dates allowed in ISO 8601 which use the alternative described as "basic" rather than "extended". This alternative specified in the standard uses the following date pattern: YYYYMMDD (hours, minutes, seconds may also be added). It is also used for other encodings specified in ISO 8601, e.g. date ranges, which are in the form of YYYY/YYYY (in which case start and end portions are not parsed). The ISO 8601 basic expression has been used widely in MARC 21 date elements.</description></item><item><label>marc</label><value>marc</value><description>This value is used only for dates coded according to MARC 21 rules in field 008/07-14 for dates of publication/issuance. Thus, this would only apply to the attribute in dateIssued. Examples include: 19uu (a MARC convention to show unknown digits in a date), 9999 (a MARC convention showing that the end date has not occurred or is not known).</description></item><item type="added"><label>text</label><value>text</value><description>This value is used only for dates coded according to MARC 21 rules in field 008/07-14 for dates of publication/issuance. Thus, this would only apply to the attribute in dateIssued. Examples include: 19uu (a MARC convention to show unknown digits in a date), 9999 (a MARC convention showing that the end date has not occurred or is not known).</description></item></items></code-table>
>> 
>>