Flat Packaging Format (Possible OOXML extension 30114-3).

[Jesper Lund Stocholm]

Hi Alex,

 

I think the option you mention regarding that "Microsoft" appears in
namespace names is rather undesirable. I'd prefer us to remove the
"microsoft" literal from the namespaces and let vendors document their
deviances from the standard as at least Microsoft is doing it. We could
even make a note on our webpage raising this issue with vendors being
non-compliant.

 

Jesper Lund Stocholm

Senior Architect

 

m: +4530945570

jesper.stocholm at ciber.com 

www.ciber.com <http://www.ciber.com> 

 

 

 

 

  <http://www.facebook.com/ciber>    <http://twitter.com/ciberinc>   
<http://www.linkedin.com/groups?mostPopular=&gid=123828> 

  <https://mvp.support.microsoft.com/profile/Jesper.Lund.Stocholm> 

 

From: Alex Brown [mailto:alexb at griffinbrown.co.uk] 
Sent: 2. juli 2012 16:20
To: SC 34 WG4
Subject: Flat Packaging Format (Possible OOXML extension 30114-3).

 

Dear all,

 

At the just-finished Brazil meeting I gave a brief presentation
outlining a proposal for an alternative "flat" representation of OPC
packages. Please find attached a draft for such a spec.

 

I have included some editorial notes which contain some important
queries. I have attempted to reverse-engineer the format from what
MS-Office does so as to give this standard a chance to integrate with
the existing OOXML ecosystem, and to base it on something which has been
implemented. However, some guesswork was of course necessary, so
feedback would be valuable.

 

A couple of points of particular interest:

 

1. The namespace in existing implementations contains "microsoft", and I
have left this as-is. Apart from the PR dimension I don't see this as
significant as Namespace Names are merely arbitrary strings, and I think
it is more important we plug in to existing files which may be out there
then start with an incompatible freshly-minted Name (for which I can see
no benefit).

 

2. Unfortunately, Microsoft has elected to name one of its elements
"xmlData", which violates the spirit - and maybe the letter - of the XML
Recommendation. I have however left this as-is as most tools in practice
do not register this phenomenon. Thoughts?

 

- Alex.

 

 


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud
service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20121008/46971e5c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8715 bytes
Desc: image001.png
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20121008/46971e5c/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2373 bytes
Desc: image002.png
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20121008/46971e5c/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2317 bytes
Desc: image003.png
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20121008/46971e5c/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2449 bytes
Desc: image004.png
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20121008/46971e5c/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4940 bytes
Desc: image005.png
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20121008/46971e5c/attachment-0009.png>