[wpkg-users] xml Elements and attributes

[Daniel Dehennin]

Charles Gargent <charlesgargent at gmail.com> writes:

> Hi

Hello,

> In the packages xml file the exit code data is stored in an element,
> can you change it to be stored in an attribute?
> ie
> <remove cmd='msiexec /x {23170F69-40C1-2701-0457-000001000000} /qn
> /norestart' exitcode='any' />
> instead of
> <remove cmd='msiexec /x {23170F69-40C1-2701-0457-000001000000} /qn
> /norestart'><exit code='any' /></remove>

I don't think it's a good thing. Think about having more than one
possible exit code, it seems odd to me to have multiple occurrences of
the same attribute, it seems more natural to have multiple elements, and
this conflict with your following proposal.

>
> Can you change all the data to be stored in an element rather than
> some attributes some elements?
> ie
> <packages>
>   <package>
>     <id>7-Zip</id>
>     <name>7-Zip 4.57</name>
>     <check>
>       <type>uninstall</type>
>     </check>
> etc...
>   </package>
> </packages>
>
> instead of
>
> <packages>
>   <package id="7-Zip" name="7-Zip 4.57" revision="1" priority="150"
> reboot="false">
>   <check type="uninstall" condition="exists" path="7-Zip 4.57" />
>   <install cmd='msiexec /i "%AIP%\7-Zip\7z457\7z457.msi"
> transforms="%AIP-common%\7-Zip\7z457\7z457.mst" /qn /norestart' />
>   <remove cmd='msiexec /x {23170F69-40C1-2701-0457-000001000000} /qn
> /norestart'><exit code='any' /></remove>
>   </package>
> </packages>

Here it seems more natural to me to have attributes instead of elements,
the package attributes refer to the package, having them as children
looks strange to me.

For install/upgrade/remove, having children elements looks good to me,
but is more verbose:

--8<---------------cut here---------------start------------->8---
<install>
  <exec>
    <command>msiexec…</command>
    <exit>0</exit>
  </exec>
  <exec>
    <command>reg add…</command>
    <exit>0</exit>
  </exec>
</install>
--8<---------------cut here---------------end--------------->8---

NB: using <exec/> may permit to use something else than <command/>, for
example calling JScript functions directly from the package definition?

Regards.
-- 
Daniel Dehennin
RAIP de l'Orne