Hi Jan,
My responses in-line. Thank you for the response!
-Clay
On Mon, 14 Jun 2010, Jan Damborsky wrote:
Hi Clay,
On 06/10/10 11:06 PM, [email protected] wrote:
Hi Jan,
I'm concerned about sc_conv.ksh, it would be good to add a comment what
it's doing exactly and is this expected to be run on the AI client or AI
server, at least for anyone stumbling across it.
I agree - I have added comment section to the beginning of the script -
could you please take a look at that comment and let me know if
it might appropriate clarify the purpose of this script ?
The updated webrev is available at
http://cr.opensolaris.org/~dambi/bug-15723-cr/
Delta webrev
http://cr.opensolaris.org/~dambi/bug-15723-cr-delta/
Your comment helps one understand the script quite a bit! Thank you. I'm
concerned that sc_conv.ksh is not applicable for running on the server due
to the concerns cited below.
As far as utilizing XSLT for SC manifest conversion, while I can see
that XSLT is the solution for manipulating XML files in CUD,
I am not convinced that moving to XSLT in sc_conv.ksh is the right thing
to do at this point. sc_conv.ksh is tied to the existing infrastructure
which is going to be removed and replaced with the new one, thus I am
not sure it is worth to invest that effort. Why not to introduce
XSLT integrated with new CUD effort after it is fully exercised ?
The main reason to use XSLT is that it is XML compliant. For example,
sc_conv.ksh breaks on the test case I provide called "sc.xml"[1] which
publish-manifest(1) will happily accept from an admin.
If sc_conv.ksh is only to be used on the AI client than regular
expressions and expecting a certain formatting to the XML is okay (as
publish-manifest should somewhat reorder the XML on output[2]) but
otherwise XML can be quite free-form with regards to whitespace and value
ordering and it seems sc_conv.ksh breaks in these cases.
[1]: test-case which sc_conv.ksh fails on
http://cr.opensolaris.org/~clayb/SC_using_XSLT/test_cases/sc.xml
[2]: another test-case which sc_conv.ksh fails on (duplicate type and
name attributes for the description element) which is post
publish-manifest(1):
http://cr.opensolaris.org/~clayb/SC_using_XSLT/test_cases/default_reorder.xml
Also, looking at XSLT version, it is unnecessarily complex given
its goal. sc_conv.ksh is mostly targeted to the admins who will use it
to convert existing SC manifests. sc_conv.ksh in current form is
easy to understand which I believe is the advantage in case
some minor modifications are desired.
I see sc_conv's regular expressions to be very painful to catch possible
errors in (certainly I've picked on a few but I might be missing more),
versus reading the XSLT expressions from convert.xslt. XSLT is a nice
formalized way for dealing with XML versus regular expressions which are
highly nasty to correctly handle XML and quite complex.
I don't believe folks should need to modify the scripts we provide but I
believe the extra verbosity of an XSLT stylesheet allows for far more ease
of modification, in the unlikely event it is necessary.
I can see that this might be a good exercise to give XSLT a try,
but I would like to treat that separately, since XSLT is not something
we have appropriately exercised yet, thus might constitute the risk
I believe is not worth to undergo in this particular case.
If it seems plausible, do you think I could file separate bug for this ?
I believe xsltproc(1) which can use convert.xslt -- part of libxml2 has
had far more users than our code and further the W3C has ratified XSLT 1.0
which we are here using; again the W3C XSLT standard has very likely had
far more users than any code we've written for slim_source. Lastly,
empirical testing shows the XSLT conversion to do as expected.
To be honest, I don't understand your concern about polluting our
gate with another shell script given the fact that it will be removed
when no longer needed (as soon as AI/DC manifest rework is integrated).
I would like to see us work towards our goals at all times and not just
occasionally. Code live far longer than expected more often than not (e.g.
why is libspmi still in our gate? ;) )
Please let me know what you think.
My parting thoughts would be that we should go with the expected, industry
technology now and not later. That I believe, would be XSLT.
[snip...]
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
