abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elias Torres <el...@torrez.us>
Subject Re: Graceful handling of non-atom 1.0 feeds
Date Mon, 12 Jun 2006 17:58:20 GMT


James M Snell wrote:
> Elias Torres wrote:
>> On 6/11/06, James M Snell <jasnell@gmail.com> wrote:
>>> There's actually a very practical use for this arbitrary XML parsing
>>> mechanism that's already in the code.  When you call
>>> content.setValue(...) on an atom:content with XML content, you can pass
>>> in an XML string.  The parser will parse it to create the appropriate
>>> ExtensionElement object to set as the child of the content object. This
>>> also works when setting XHTML content on the Content and Text objects,
>>> making it very simple for us to construct XML and XHTML nodes.
>>>
>>> The API is something like...
>>>
>>>   entry.setContentAsXml("<a><b><c/></b></a>", baseUri);
>> Sure, but that's not as important. That's also the XML parser's job. :)
>>
> 
> The parsers job? The above API is used for building feed and entries,
> not parsing them.

I guess I don't understant what's the feature of setContentAsXML. I was
just trying to say that if we needed to build XML/XHTML nodes, etc, that
should be the DOM api's job and not ours.

> 
>>> Regarding spec compliance, I had been kicking around the idea of a
>>> Validator.INSTANCE.validate(...) mechanism.  You could pass in any of
>>> the FOM objects and have it validate against the spec.  This would also
>>> allow us to configure validators of various strengths and purposes (e.g.
>>> StrictValidator, LiberalValidator, UlterliberalValidator,
>>> MyGdataValidator, Atom03Validator, etc).  It also provides a clean
>>> separation between the parser and the validator.
>>>
>> This is more like what I was looking for, except maybe I'd rather have
>> this at parsing time, no? It'd be too slow to parse, then walk the FOM
>> for validation. Maybe it's the other way around, too slow to do it at
>> parse time, but if we have validation modes, then we would skip
>> validation. Hopefully this is something that can set Abdera apart, a
>> pluggable Atom validation scheme.
>>
> 
> So long as it is turned off by default.  Via the ParserOptions mechanism
> we can have a setValidator/getValidator API that can be used by the
> parser to determine whether or not a given element is acceptable or not.
>  There are a couple of challenges with this however.  One, we either do
> the validation up front, requiring the entire XML stream to be consumed
> right from the start (leading to significantly increased up-front memory
> consumption) or we do the validation incrementally as each element is
> requested leading to validation errors that may not show up unless those
> specific invalid entries are requested.  Also, I want to be able to
> validate newly created elements, e.g.,
> 
>   Entry entry = Factory.INSTANCE.newEntry();
>   // set entry properties
>   Validity v = Validator.INSTANCE.validate(entry);
> 
> In this case, the parser is not involved at all.  It's just the
> validator operating against an in-memory object model.
> 
> The right solution is likely to be a combination of these two approaches.

Right, good points. This is why I'm not sure where it really fits
nicely. I'm just advocating that we give validation the time of day.

> 
> - James
> 

Mime
View raw message