abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Graceful handling of non-atom 1.0 feeds
Date Mon, 12 Jun 2006 17:00:51 GMT

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.

>>
>> 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.

- James

Mime
View raw message