[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] One strictly conforming document?
Dear Doug, Le 3 févr. 09 à 17:15, Doug Mahugh a écrit : > It's worth noting that the ODF metadata mechanisms don't allow for > the use of a private/custom schema to tag content within a > document. And that use case has value to many users. So if we > decide that ODF won't be able to support those types of scenarios, > for whatever reason, we should not be surprised to find that users > who need such capabilities will look elsewhere. From a purely commercial point of view, I have both customers and prospects who consider the ability to use custom schemas as an unwelcome feature. Customers (but again, mine may not be yours) wants predictability, and they also want one file format to be used for what it's best. Custom schemas are therefore not so much a must have feature for ODF, but rather is a disctinctive capability of XML. By taking a look at most of the other TCs inside the OASIS consortium, you will see that XML is all about that: creating new kinds of specialized markup languages, and it ultimately amounts to design a custom schema that will be agreed by the rest of the standard development stakeholders. > > > Consider the trivial example of a pre-existing document, created > years ago, which needs to be logged in to a content management > system that requires an abstract to be identified for each > document. If the format of the document is HTML, then a div with > class="abstract" can be used to tag the appropriate paragraph(s) as > the abstract. If the format of the document is DOCX, a customXml > element with element="abstract" can be used for the same purposes. > In both cases the document content remains valid HTML or > WordprocessingML, while the user adds the custom semantics required > for their purpose. The custom semantics can be (and should be) > ignored by others. The user is free to innovate quickly, and does > not have to think in terms of a tradeoff between strict compliance > and flexibility/business value. They can, and do, have the best of > both worlds in such scenarios: strict compliance to a standard, and > freedom to innovate quickly for their own specialized purposes. I would argue this to be a "dangerous" feature for a number of reasons: - on the level of the usage scenarios, you cannot strictly circumscribe the actual distribution and editing of documents. Therefore, you could end up by having issues resulting of concurrent modifications and clutter created by the documents circulation (aka the network effect). - what about safety? - if you really need a custom schema, you are essentially breaking the interoperability. If you have the need to create a custom schema, then you have the need to spread it around, wether in your organisation or outside your organisation. And this is just a simple binary scenario: inside your org, outside it. I'm not talking about real collaboration here. - precisely because you need to spread your document with your custom schema, then you may want to agree with other stakeholders (your suppliers, for instance) on exactly what your schema is. And then you end up with two questions: why not simplify the file format to include only what you need and last but not least, what applications will be able to process your custom schema and / or your new file format? All this looks a bit far-fetched to me... > > > I think ODF would benefit from being as supportive of such scenarios > as HTML, IS29500 and other formats already are. No committee can > anticipate every possible class of extension that users might find > useful, so I think the format itself should allow for clean, simple > tagging of content according to schemas that may never be > standardized, and may never be widely known or used. Done > correctly, such tagging puts no burden on simple interoperability > between word processors (which typically ignore it), but can enable > other types of interoperability that many people find valuable. See the points above: I'd rather say that there are not many users who have this need and when they do, they usually end up using an ad-hoc or industrially designed file format based on XML that does one thing well: to describe, encapsulate and represent their data in their own, specific way. By then you won't need ODF. You need to change to something else, in my humble opinion. Best, Charles-H. Schulz. > > > - Doug > > > -----Original Message----- > From: Patrick Durusau [mailto:patrick@durusau.net] > Sent: Tuesday, February 03, 2009 7:38 AM > To: office@lists.oasis-open.org > Subject: Re: [office] One strictly conforming document? > > Rob, > > robert_weir@us.ibm.com wrote: >> Patrick Durusau <patrick@durusau.net> wrote on 02/03/2009 09:15:01 >> AM: >> >> > <snip> >> This is really a red herring. However bad you think interoperability >> would be in that case, you must admit that it is made worse, not >> better, >> by extending the documents with private schemas. >> > Sorry. Did I say anything about private schemas? >> Also consider that the problem you describe above can be addressed >> and is >> being addressed by interoperability testing, the work of the OIC >> TC, etc. >> The ODF vendors, most of them at least, have a keen interest in >> improving >> interoperability in that area. However, allow ODF documents to be >> freely >> extended with private schemas without the user's choice, and you >> have made >> the problem much much harder. We can improve interoperability >> where we >> agree on a schema. But it is considerable more difficult to do >> that when >> a private schema is involved, one which perhaps is not disclosed. >> Remember >> a private schema extension is not even required to be made >> available on >> RAND terms, let alone made freely available. >> >> > Well, if I had said that private schemas would help here that might > be a > valid point. But I didn't. > > Actually using the ODF metadata mechanism is the "correct" solution in > my view to the problem posed. > > But I pointed it out to merely illustrate that simply saying *ODF* > really loud doesn't solve the interoperability issue. > > Nor does wanting to market ODF mean that it automatically meets any > user > requirement. > > Yes, I really do think that ODF 1.2 with the new metadata features, > can > meet many user requirements but that doesn't mean that I think it > meets > all user requirements. > > The question (to me anyway) is whether we develop ODF to meet an ever > expanding universe of user requirements or do we promote ODF * > (whatever > version we are at) as meeting user requirements? > > I readily concede that I enjoy finding ways that ODF can meet user > requirements but for me, user requirements and not the choices of IT > departments or marketing strategies of vendors remain primary. > > Remember that I come from a user community and still think of software > as meeting user requirements and not the desires of vendors. It may > really be that simple. I don't see the world as a vendor. > > Hope you are having a great day! > > Patrick > > -- > Patrick Durusau > patrick@durusau.net > Chair, V1 - US TAG to JTC 1/SC 34 > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 > Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > Charles-H. Schulz Associé / Founding Partner, Ars Aperta
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]