abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harris Boyce III" <harris.r.boyce....@gmail.com>
Subject Re: Thoughts for version 0.3.0
Date Fri, 08 Dec 2006 17:59:58 GMT
On 12/8/06, James M Snell <jasnell@gmail.com> wrote:
>
> Harris Boyce III wrote:
> > FWIW, here's my input...
> >
> >> > Now that 0.2.0 is out the door, here's what I'm thinking for 0.3.0
> >> >
> >> >  * I'd like to separate out the IRI stuff into it's own project as was
> >> >    recently discussed.
> >>
> >> +1
> >>
> >
> > I haven't found any evidence of IRI support in .NET so, whether it's
> > in Abdera or another project, my guess is it will need to be
> > implemented as well.
> >
>
> Unfortunate.  I believe that IRI support was pulled from Java6 as well.
>
> I've started the process of extracting the IRI code out into it's own
> "g13n" (globalization) project that, at least for now, will sit in our
> dependencies module.
>

The closest utility that I found was an IdnMapping class [1], though
it only references RFC 3490 and not 3987.  I'm more concerned with
getting the parsing situated first and then tackling IRI support and
the like.

> >> >  * I'd like to review the use of Axiom and decide once and for all
> >> >    whether or not we're going to keep it or ditch it.  If we keep it,
> >> >    we should update to the latest release.  If we ditch it, we need
> >> >    to come up with an alternative.
> >>
> >> Agreed, this needs to get resolved.  Personally, I'm in favor of
> >> reducing our total number of dependencies, so if we can implement a
> >> parser that doesn't pull in Axiom I'd be all for it.  On the other
> >> hand, if we do that by essentially duplicating all of Axiom, that
> >> would be unfortunate.
> >>
> >
> > I've been studying the Axiom code as there's no equivalent in .NET, so
> > an incremental parser will be a large part of work for a .NET
> > implementation.  This prompts me to consider the pros/cons to such a
> > parser when there's built-in support for XML object serialization.
> > But that's another conversation...
> >
>
> I fully expect that there will be differences in the way the various
> language implementations function.  Having exact feature-to-feature and
> behavior-to-behavior parity should not hold things up.  Just do what
> works and get it as close as you can.
>
> > [snip]
> - James
>
I think I'm leaning towards utilizing the XPath cursor model [2]
that's available to provide easy support for queries against the FOM
instead of using the DOM impl.  And I don't foresee this causing any
headaches when it comes time to implementing security (XML-Sec).  The
cursor model would also allow the FOM to be built as accessed, which
might be nice as well.

- Harris

[1] http://msdn2.microsoft.com/en-us/library/system.globalization.idnmapping.aspx
[2] http://msdn2.microsoft.com/en-us/library/system.xml.xpath.aspx

Mime
View raw message