OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oiic-formation-discuss] Welcome!

2008/6/5  <robert_weir@us.ibm.com>:

>> Perhaps NVDL would help there, certainly xproc will be a useful tool.
> To my knowledge, no ODF implementation today actually writes additional
> content to an ODF document in a foreign namespace, although the standard
> allows this.  But what I have seen is an application adding additional
> attributes into an existing ODF namespace.  But this is a simple validity
> error and is caught directly by any validating parser.  But Rick's
> pre-validation NVDL is something we can add to our bag of tricks, in case it
> ever comes up in the future.

So a 'valid' file, with other namespaced content would be deemed
invalid by a simple validating parser check?
Are additional attributes (namespaced) also allowed?

> When we talk about conformance with ODF, we're really talking about two
> things, since the ODF standard defines document conformance as well as
> application conformance.  The former is the easier one to test, and lends
> itself to automation.
> A full check of ODF document conformance would need to do something like:
> 1) Verify the document file name extensions and/or MIME content type and
> verify that it matches the contents of the underlying document.  An ODT file
> containing a spreadsheet should be noted, for example.
> 2) Verify the correctness of the Zip container.  Is it actually following
> the referenced Zip specification?
> 3) Verify the referential integrity of the package.  Does the manifest
> reference files that don't exist, for example?  Are all the required parts
> present?

Generally a programming task?
File name matching etc,
What about the compression?

> 4) Verify the Relax NG validity of each of the contained XML documents,
> pre-processing as needed.

How would you define pre-processing then?
As needed seems a bit vague?
1. Remove all non ODF specified namespaced elements?
2. Remove all non ODF specified attributes?
 (Or not, since there is a potential invalidity here?)
 (what of namespaced attributes in non ODF namespaces?)

> 5) Verify additional referential integrity constraints.  For example, the
> content XML typically refers to named styles in the syles xml.  These
> cross-document references need to be checked.

Schematron sounds ideal for this.

> 6) Verify the various micro-formats contained in ODF.  There are some things
> that are not easily expressable as a schema type, even using a regex.  For
> example, spreadsheet functions, with its hundreds of functions, some with
> variable arguments, which could take cell ranges, named ranges, or constants
> as parameters.  These are defined in the standard via EBNF.  A full
> conformance test would take each of these attributes and verify that they
> match the production rules defined by the EBNF.

Has anyone created a full grammar for these?
Is grammar based validation most appropriate?
How to collect them for validation?

Not an easy one one by the sounds of it.
More appropriately, how to formally define validity for these cases.

> 7) Other recommendations of the ODF standard, even where not conformance
> requirements.  These should be checked, and warnings (not errors) emitted.

Good. Second definition required, when warnings and when 'errors'

>  For example, we have a number of accessibility best practices that could be
> statically verifiable. Similarly, we can have portability warnings.  For
> example, a spreadsheet can have as many rows as it wished, but for
> portability we might recommend no more than 64K rows.

Might? Shouldn't this spec be explicit? How to validate against 'might' :-)
How to recognise these 'recommendations' in the spec?

> There are probably other pieces as well, but that's an outline of what we
> could do for document conformance.  Ideally I'd like any such tool to be
> event-driven (like SAX) and pluggable, so other modules can be independently
> developed and later added.

xproc seems a good candidate wrapper.
Ordering and when to halt then becomes an issue.

How to link in programmatic(or shell scripted) validation
with xml based validation.

Far more solid start Robert, thanks.
Is there any requirement for an instance to 'look alike' in two

I've heard that expressed as a definition of portability in the past


Dave Pawson

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]