Re: sanity check

On Tue, Oct 2, 2012 at 3:37 AM, James Fuller <jim@webcomposite.com> wrote:

> On Tue, Oct 2, 2012 at 9:21 AM, James Clark <jjc@jclark.com> wrote:
> > On Oct 2, 2012, at 1:19 PM, James Fuller <jim@webcomposite.com> wrote:
> >
> >> * in '5 Security Considerations' we assume that XML Canonization is a
> >> security issue only, we may want to separate this out, pointing out
> >> the various links to http://www.w3.org/TR/xml-c14n11/ . Worried that
> >> this important information is being buried here.
> >
> > The spec currently links to the IETF version of the C14N spec; this
> > should probably be changed to point to the W3C version.
> >
> > I don't see how describing a security issue in the Security
> > Considerations section is burying it.
>
> I use xml canonisation all the time for precise diff calcs that have
> nothing to do with security (for example genetic algorithm fitness,
> which must characterise precisely differences between 2 files) … I
> even suspect that xml canonisation is used more outside of security
> (as there is woeful little done with xml enc/sig) then within it … but
> 'horses for courses' I am equally fine where it is.
>

I agree that that are other uses, but all the same I think people who need
c14n will find it without much problem.  I'm curious about your
experimentation with Genetic Algorithms.  I worked a fair bit with GA & GP
in the 90s.  You actually have me wondering about application of a
MicroXSLT to GP.  Anyway do you happen to have a paper on your work?



> >> * I think the '1. Introduction' is far too verbose and could do with
> >> stating very clearly the differences in non normative terms with XML
> >> 1.0 right up front or perhaps just a link to B.1 Syntax is all that is
> >> needed.
> >
> > There are 3 "motivational" paragraphs that could be cut, but I think
> > they provide useful context for somebody coming to the spec without
> > any XML background. What harm do they do?
> >
> > I don't mind linking to B.1 in the intro, but I don't want to repeat
> > B.1 nor move it into the body of the spec: the spec should not be
> > targeted at XML experts.
>
> to echo John's comment … we need the first paragraphs to 'speak' to
> those who have not drunk the XML Koolaid but really we have 3
> audiences to speak too;
>
>   I) no knowledge of XML
>
>   II) tried xml and found it too difficult (had a sip of the XML Kool
> aid, spit it out)
>
>   III) xml hard core (drinking XML Kool Aid)
>
> we should say to I) what you can use microxml for
>
> we should say to II) why microxml is easier to use then xml 1.0
>
> we should say to III) that they should recc using microxml to their
> non xml hard core friends with no fear about incompat with XML
>

I just re-read it carefully, and I don't really find anything we should
cut.  Not surprising as almost everything there was added with very careful
deliberation.  Of course I'm pretty close to things so maybe my perceptions
are skewed, but in my Chrome print preview the entire spec is 7 1/2 pages
and the intro is just a bit over half a page.  I think in absolute terms,
that's not too long for an intro.  Yes it's a large proportion of the spec
compared to some other spec, but generally because those other specs are so
verbose in the rest of their matter.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji