RE: har parser flexibility

[Patrick Meenan]

Thinking about it a bit more, it might be easier if the following rules are specified:

 

-          Custom fields and elements MUST start with an underscore (and spec fields should never start with an underscore)

-          Parsers MUST ignore all custom fields and elements if the file was not written by the same tool loading the file

-          Parsers MUST ignore all non-custom fields they don’t know how to parse

 

This will solve both the problem of newer files being able to be loaded by tools that only understand an older spec.  It also allows tools to store custom data in the files without breaking other tools and eliminates the possibility of collision in names between custom fields and newer specs.

 

This mostly only matters for tools that will actually parse the files, not tools that can only save the files out for export to other tools.

 

Thanks,

 

-Pat

 

From: Patrick Meenan [mailto:patm...@gmail.com]
Sent: Thursday, October 01, 2009 7:18 AM
To: http-archive-...@googlegroups.com
Subject: har parser flexibility

 

Not to get it looking too RFC-like but any chance we can get some verbage in there along the lines of “parsers MUST ignore xml elements that are not part of the determined specification version and were not generated from their own tool.  The determined specification version is the lesser of the version of the file itself and the highest version that the reading tool knows how to read”? 

 

Granted, I’d expect most implementations would protect themselves but this would allow for files written to a newer spec to be loaded by older tools and for individual tools to include tool-specific information that is not (or has not yet become) part of the spec.  By requiring compliance at the actual spec level it also protects a tool that knows how to read 2.0 files from mis-interpreting a 1.1 file with custom fields in case one of the custom field names collides with one in a newer spec.

 

Thanks,

 

-Pat

[Patrick Meenan]

[Simon Perkins]

Hi Pat,

 

I like that idea but with a slight refinement of item #3:

 

-          Parsers MUST ignore all non-custom fields that they don’t know how to parse because the minor version number is greater that the maximum minor version for which they were written.

 

And an additional item #4

 

-          Parsers can reject files that contain non-custom fields that they know were not present in a specific version of the spec.

 

This would allow a 1.1 parser reading a 1.1 file to reject a field or tag called “foo” because it wasn’t in the spec and it doesn’t start with an underscore. However, it would not be rejected if the same parser was supplied in the future with a 1.2 file with same tag because it wouldn’t have in-built knowledge of the version 1.2 spec.

 

I think that’s a usefully addition so that we can quickly flag any tool that’s producing an output with misspelt optional values, e.g. “browsr” instead of “browser” in a 1.1 file.

 

Regards

 

Simon

[Patrick Meenan]

Looks good to me.  Achieves the general goal I was looking for to allow for backward compatibility with newer files loaded by older tools and for apps to store custom information that are not part of the spec in the files (which will let many tools use it as the primary file format instead of just an export/import).

 

Thanks,

 

-Pat