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

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

From: Lieske, Christian <christian.lieske@sap.com>
Date: Thu, 30 Aug 2007 08:38:37 +0200
Message-ID: <544FBEB6875DAA46A08323B58D26B80102314853@dewdfe14.wdf.sap.corp>
To: <public-i18n-its@w3.org>
Hi there,

Here's my suggestion. I guess a good place for the text would be the end of
the overview of the best practices for developers (ie. just before BP 1).
Possibly we may want to go for a sub-heading like "General Remarks on
Adapting Schemas".

Thanks to Felix for his input to this.

Cheers,
Christian
===

The "How to do this" parts of this document often contain statements related
to schema creation or modification. The statements pertain to one of the
following state-of-affairs:

1. creating a schema from scratch
2. modifying an existing schema 

The following aspects may need to be taken into account when working on both
of these topics:

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'.

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).

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.
===   
Christian Lieske
MultiLingual Technology Solutions (MLT)
SAP Language Services (SLS)
SAP Globalization Services
SAP AG
Dietmar-Hopp-Allee 16
D-69190 Walldorf
Germany
T   +49 (62 27) 7 - 6 13 03
F   +49 (62 27) 7 – 2 54 18
christian.lieske@sap.com
http://www.sap.com

Sitz der Gesellschaft/Registered Office: Walldorf, Germany

Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo
Apotheker (stellvertretender Sprecher/Deputy CEO), Werner Brandt, Claus
Heinrich, Gerhard Oswald, Peter Zencke

Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board:
Hasso Plattner 

Registergericht/Commercial Register Mannheim No HRB 350269

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine
Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.

Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail in
error, you are hereby notified that any review, copying, or distribution of
it is strictly prohibited. Please inform us immediately and destroy the
original transmittal. Thank you for your cooperation.


Received on Thursday, 30 August 2007 06:38:51 UTC

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