Re: [oiic-formation-discuss] (1)(f) and (1)(g) -- audience and working language

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/11 Sam Johnston <samj@samj.net>:

> On implementors and integrators:

> I think it best to have a title and a brief explanation as well, as these
> are important points - we could afford to burn a few more cycles here to
> make sure the TC are considerate of their audience.

You'll need some sort of definitions section, glossary etc.
Even if Oasis won't have it in their charter, it should be available.
Pull the one from my section and lift it up to a new page to collate
definitions? With the problems we're having with definitions it
should add value.


>
> On portability:
> This is something I have already been giving a good deal of thought to as
> one of the key drivers for ODF is metadata/search/archiving. I would like to
> see a 'profile' developed (as a deliverable) which would exclude certain
> 'difficult' functionality from documents, like macros for examples, links to
> other documents, macros, etc. and for want of a better name this profile
> could be called 'ODF/A' in line with its 'PDF/A' predecessor... or at least
> it could be the precursor to a separate TC on this topic.

-1 Sam. Rationale. I don't see links as a problem, xml hacks them well.
Macros are an application compliance issue more than a profile variant?



 Again the 1.0
> release could be fairly limited (eg excluding multimedia) but I think there
> should be some demand for such functionality, which could be somewhat
> aligned with PDF/A to avoid data loss (currently the most attractive
> archiving option is likely a lossy export to PDF/A - an extra unnecessary
> step IMO).

Not yet ready to commit, but I'd guess that 1.0 will be restricted.




>
> On presentation:
> Touching on the points raised before about presentation, I think that in the
> dawning age of the semantic Web 3.0 (there, after resisting for so long I've
> finally said it), where data takes precedence over form, I believe our
> interop efforts should if anything sacrifice 'pixel perfect' rendering for
> data integrity if necessary.

-1, since an end subjective user assessment is key IMHO.
Pixel perfect is nearly impossible, agreed, but presentation has been proposed
as important and I agree. If we can't define it, scope it and explain
how to test it
then it gets deferred. Until then I'd like to see it remain.


regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk