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

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

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 12 Sep 2007 22:58:05 +0900
Message-ID: <46E7F06D.4060005@w3.org>
To: "Lieske, Christian" <christian.lieske@sap.com>
CC: public-i18n-its@w3.org

Hi Christian,

Lieske, Christian wrote:
> Hi there,
>
> Here's an modified version of the draft. The modifications should address the feedback which was sent.
>
> 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 new schema
> 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, Open Document Format, Office Open XML,
> XML User Interface Language, Universal Business Language, ... Those formats 
> have many insights 'built-in'.
>
> 2. 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.
>
> 3. 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 difficult to realize for DTDs.
>
> 4. Each schema language provides ways of extending or modifying existing
> schemas. XSD for example provides statements such as "import",
> "include", or "redefine" as well as mechanisms such as type
> substitution/derivation.
>   

I think what follows "XSD for example" needs some change. "import" or 
"include" are modularization mechanisms, working on different or the 
same namespace. "Redefine" is a modularization mechanism working on the 
same or a different namespaces of an external schema. However, type 
substitution / derivation can be (and is) used in single schemas, 
without any modularization of schemas at all.
I would propose to change 4 as follows:
[Each schema language provides different ways of extending or modifying 
existing
schemas. An example is the include, import or redefinition of external 
components in XSD.]

with links like this:
include: http://www.w3.org/TR/xmlschema-0/#ref23
import: http://www.w3.org/TR/xmlschema-0/#ref31
redefine: http://www.w3.org/TR/xmlschema-0/#ref52

> 5. Some processors do not implement support for all schema language constructs.
> Thus, a schema which works in one environment may not work in a different one.
>   

There are two reasons for this behavior: one of the two processors (or 
both) does not implementing a feature correctly, or the two processors 
have a different conformance level. Esp. the use of "include" is not 
required in all conformance levels of XML Schema, see
http://www.w3.org/TR/xmlschema-1/#concepts-conformance , the 2nd 
"Definition". and the list of constraints at 
http://www.w3.org/TR/xmlschema-1/#outcome-src . I think this difference 
needs to be made clear, so that people don't just say "may processor 
does not work", but look closely into its implementation description.
Hence, I'd propose 5 as:

5. Some processors do not implement support for all schema language 
constructs, due to erroneous implementations or difference in 
conformance profiles (see e.g. the conformance requirements to <loc 
href="http://www.w3.org/TR/xmlschema-1/#concepts-conformance">XML Schema 
part 1</loc>. Thus, a schema which works in one environment may not work 
in a different one.

> 6. What is 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 will provide a change proposal for 6 later.

An additional proposal: we need to make clear that this section is only 
a start for people who want to modify schemas. We should point them to 
good books, tutorials. I would propose to add a list of these to the 
"More resources" part.

Felix
Received on Wednesday, 12 September 2007 13:58:18 UTC

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