[Cuis-dev] YAXO and entity

Juan Vuletich juan at jvuletich.org
Mon Sep 27 12:02:52 PDT 2021


Never mind.

If you later find some time to review the code, disregard my first 
proposal, and check what I've just sent to the list: 
UnsavedChangesTo-YAXO-jmv.002.cs.st . This changeset enables the 
conversion that Hilaire found disabled in YAXO, but only if the result 
is a valid Cuis Character.

Thanks,

On 9/27/2021 3:15 PM, Phil B via Cuis-dev wrote:
> Sorry, I didn't have time to review the code.  I just mentioned these 
> in case you were considering changing YAXO behavior.  Disregard if not 
> helpful. :-)
>
> On Mon, Sep 27, 2021, 2:09 PM Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>> wrote:
>
>     On 9/27/2021 1:10 PM, Phil B via Cuis-dev wrote:
>>     Juan,
>>
>>     Two things:
>>
>>     1) When reading XML files you have to be able to consume CR
>>     and/or LF as the majority of XML files are going to come from
>>     non-Smalltalk sources using who-knows-what conventions.  This
>>     goes for the structure as well as the content.  So we can't say
>>     'just use LF'.  It is fine (even preferred) to emit only LF (for
>>     a generic end of line, not an encoded entity) when writing XML
>>     files.  See https://www.w3.org/TR/REC-xml/#sec-line-ends
>
>     Isn't this currently the case? Can you attach an XML (inside a
>     zip!) showing it is not?
>
>>     2) When you want to ensure your CR's and/or LF's are preserved
>>     'as is' in attributes/nodes, they need to be encoded as Hilaire
>>     is doing.  They need to be unencoded along with other entities
>>     when parsed.
>
>     Same as before. Isn't this the case? Do you have an example to
>     show otherwise?
>
>>     If you don't encode your CR's inside attributes/nodes, I believe
>>     many/most XML generators will translate them to LF's (or even
>>     omit them) when the XML file is written per item 1.  Now whether
>>     or not Hilaire's code should want the CR's encoded is a valid
>>     point to consider as that's a content question rather than an XML
>>     one.  But it is valid from an XML standpoint to do what he is doing.
>
>     Of course. I guess you didn't see or try the code I attached on
>     Hilaire's example.
>
>     My suggestion was to ask # withCuisLineEndings to the Smalltalk
>     code extracted from the XML, prior to filing it into Cuis, so Cuis
>     code will honor the Cuis convention. In any case, it is not really
>     mandatory. Cuis will compile and run Smalltalk code in any line
>     ending convention...
>
>>     Thanks,
>>     Phil
>>
>>     On Mon, Sep 27, 2021 at 6:53 AM Juan Vuletich via Cuis-dev
>>     <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>>
>>         On 9/26/2021 10:27 AM, Hilaire Fernandes via Cuis-dev wrote:
>>>
>>>         Hi Nicolas,
>>>
>>>         I can read most of DrGeo xml files, only xml entity like
>>>         
 (carriage return I guess) and 	 (tabulation) are
>>>         not translated and kept as is when I read the file.
>>>
>>>         Hilaire
>>>
>>>         Le 26/09/2021 à 10:57, Nicola Mingotti a écrit :
>>>>         i was parsing successfully a libreoffice file with YAXO.
>>>         -- 
>>>         GNU Dr. Geo
>>>         http://drgeo.eu
>>>         http://blog.drgeo.eu
>>
>>         It looks like the attached works. Test adding
>>         #withCuisLineEndings, so that CR characters from Pharo are
>>         converted to LF:
>>
>>         | doc |
>>         doc _ XMLDOMParser parseDocumentFrom:  'Curve and slope.fgeo'
>>         asFileEntry readStream.
>>         ((doc elementAt: #drgenius) firstTagNamed: #code)
>>         contentString withCuisLineEndings.
>>
>>         I don't know the XML spec in full detail, but it looks like
>>         the conversions in the attach are needed. Anyone knows better?
>>
>>         Thanks,
>>
>>         -- 
>>         Juan Vuletich
>>         www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>>         https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>         https://github.com/jvuletich
>>         https://www.linkedin.com/in/juan-vuletich-75611b3
>>         @JuanVuletich
>>
>>         -- 
>>         Cuis-dev mailing list
>>         Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>>         https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>     Thanks,
>
>     -- 
>     Juan Vuletich
>     www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     https://github.com/jvuletich
>     https://www.linkedin.com/in/juan-vuletich-75611b3
>     @JuanVuletich
>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210927/8db9f068/attachment.htm>


More information about the Cuis-dev mailing list