W3C home > Mailing lists > Public > public-i18n-its@w3.org > July to September 2007

Re: ACTION ITEM: draft general section about extending/customizing schemas (http://www.w3.org/International/its/track/actions/1)

From: Jirka Kosek <jirka@kosek.cz>
Date: Wed, 05 Sep 2007 15:56:17 +0200
Message-ID: <46DEB581.5070908@kosek.cz>
To: "Lieske, Christian" <christian.lieske@sap.com>
CC: public-i18n-its@w3.org
Lieske, Christian wrote:

> 1. Think twice before creating your own schema. Consider strongly existing
> formats such as DITA, DocBook, OpenOffice, XUL, UBL, ... Those formats have
> many insights 'built-in'.

OpenOffice -> ODF (or Open Document Format)

> 2. The mechanisms which you can or have to use depend on the schema
> language (DTD, XSD, RelaxNG, ...). Namespace-based modularization of schemas
> for example is hard to realize for DTDs.
> 3. Very often each schema formalism provides several possibilities related
> to modification. XSD for example provides statements such as "import",
> "include", or "redefine" as well as mechanisms such as type
> substitution/derivation.
> 4. What's possible also depends on the features of the schema which the
> modification is targeting. Examples:
> - An XSD "redefine" for example only is only
> possible if the modified schema has been created with named types.
> - If you are working with XSD, your options depend on the question whether
> the schemas involved define target namespaces (techniques such as working
> "chameleon" or "proxy" schemas may be considered as solutions in certain
> cases).

I think that this point 4 is probably going to deep into internals and
quirks of one particular schema language. IMHO I would remove this part.
If not then we should also add notes that if you are using xs:redefine
you should be very careful with as this construct has problems with
interoperability (but I bet that XML schema WG will push hard for
removing such sentence during last call).

> 5. The format itself should be carefully
> checked with regard to modification capabilities. DocBook and DITA for
> example come with their own set of features for adapting them to a special
> need.

I think this should be moved directly after 1. and prefixed by something
like "If you are modifying some existing schema you should first check
its guidelines for customizing..."

  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member

Received on Wednesday, 5 September 2007 13:55:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:09 UTC