Comment on XML Schema 1.1

Comment on XML Schema 1.1

APPRECIATION
The content-based validation option made possible by the implemented by
‘assertions’ is really good and creative.


NAMESPACES
(Affects both the XML Schema and the XML standard itself.)

Prohibit local namespace declarations
All namespace declarations must be placed on the root element of the XML
document; local namespace declarations are prohibited. This prevents the
reuse of same prefix for different namespace in same document.

Prohibit double namespace declarations
A namespace might only be declared once, i.e. all elements from same
namespace will have same prefix in the same document.

Arguments
Together this will enforce a linked collection of XML Schemas to have
consistent use of namespace declarations and namespace prefixes. In XML
Schema 1.0 it is possible to make a mess of namespace declarations where
importing and imported XML Schemas use different prefixes for same
namespace.
Resolving XML Schemas.
At the same time it will make parsing XML documents using namespaces
simpler.


RESOLVING LINKED XML SCHEMAS

Local targetNamespace declarations
By allowing local target namespace declarations it should be possible to
merge all linked XML Schemas (linked by include, import and/or redefine)
into only one valid XML Schema.

Arguments
This will make it possible to implement the resolving of linked XML Schemas
as an XML Stylesheet, making the resolving more conformant and this way the
differences between different implementations of validation tools less
likely; an “official” XML Stylesheet like this could be developed under the
W3 (like the non-normative X4XD).

Value patterns
It should be allowed to add more than one value pattern (reg. exp) as facet
to a restricted simple type. With XML Schema 1.0 it is possible to do same
as restrictions to restrictions, but not as several patterns to same
restriction.

Resolving simple types
It should be made explicit that xs:anySimpleType and xs:anyAtomicType takes
any value facet, grouped by xs:choice in non-numeric, numeric and date
facets.

Arguments
This makes it possible to resolve all restricted simple types into an
xs:anySimpleType with a number of value facets including one or more
patterns defining the eventually used built-in data type.


SIMPLE TYPES

Reg. exp. for built-in simple types
The built-in simple types should all be normative defined as regular
expressions (together with text definitions), making the validation tools
more conformant.

Canonical and lexical definitions
The built-in simple types should only have one definition. It is NOT the
task of XML Schema to make standards for presentation of data, which is a
far more complex task than covered by XML Schema 1.0 or 1.1, and out of
scope. The double definitions make confusions about what is really the
correct definition.

Simple type hierarchy
The simple type hierarchy should be cleaned up and reflect the logical
relations instead of the current mixture of logical relations and
“historical” relations.

Boolean type
The built-in type ‘boolean” should restricted only to accepted ‘true’ and
‘false’, making the type more stringent.


DATA CORRECTION

The “whiteSpace” facet and “default” value attribute should expressively be
categorised as “data correction” definitions and not data validation
definitions, making it clear that such data corrections are to be made AFTER
validation. Otherwise a number of built-in simple types make no sense. Or
especially the enumerated valid values of the whiteSpace facet make no sense
(ex. collapse and replace).


Best regards,

Henrik Juul-Nyholm,
Independent IT Consultant,
http://www.linkedin.com/in/henrikjuulnyholm

Received on Thursday, 14 May 2009 09:08:27 UTC