W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2000

RE: (Summary) Implementation Experience: Notation is NOT a DERIVED type of QName

From: Asir S Vedamuthu <asirv@webmethods.com>
Date: Mon, 11 Dec 2000 08:22:02 -0500
To: <asirv@webmethods.com>, "Biron,Paul V" <Paul.V.Biron@kp.org>, "'www-xml-schema-comments@w3. org'" <www-xml-schema-comments@w3.org>
Cc: "'Ningang chen'" <nchen@webmethods.com>, "'w3c-xml-schema-ig'" <w3c-xml-schema-ig@w3.org>, "James Clark" <jjc@jclark.com>
Message-ID: <NEBBIAMHOMNDLFMEIEBAIEJNCDAA.asirv@webmethods.com>
Original comment from Asir can be found at [1] and a related comment from
James Clark can be found at [2]


[a] NOTATION is not aligned with XML 1.0 - hence incompatible. Part 2 says,
that ..

- NOTATION is a datatype 'cos "A feature of this specification included
solely to ensure that schemas which use this feature remain compatible with
[XML 1.0 Recommendation (Second Edition)"

In one of the e-mails, Henry acknowledged that "There is no connection
between them and XML 1.0 Notations." -

[b] NOTATION is not aligned with XML Infoset. 'Cos,

- Schema processor makes a contribution, at the context element information
item: [notation] or [notation system] and [notation property]. Downstream
processor should be aware of two notation information items (messy),

From Infoset - Document Information Items.[notation declarations]
From PSVI - Element Information Items.[notation] or Element Information
item.[notation system] and [notation property]

Reference -

[c] NOTATION is not a subtype of QName. NOTATION is a primitive type. 'Cos
it cannot be expressed using XML Schema Language.

[d] If an element information item has more than one attribute declared as
NOTATION datatype, schema processor does not have the capability to
contribute more than one [notation] or [notation system] and [notation

Another proposal to solve this mess,

[Step 1] Drop NOTATION declaration component (be happy, it reduces
[Step 2] NOTATION is a primitive type and is not a subtype of QName
[Step 3] NOTATION's lexical space is governed by the 'Name' production rule
from XML 1.0,

	'<!NOTATION' S Name S (ExternalID | PublicID) S? '>'
	[5]  Name ::=  (Letter | '_' | ':') (NameChar)* ...

	Reference - http://www.w3.org/TR/REC-xml#Notations

[Step 4] NOTATION's value space is the set of names from Document
Information Item.[notation declarations].[name] (s)

This is convenient 'cos, schema processor operates on the infoset and not on
the XML Syntax

	Reference -

[Step 5] Drop the following NOTATION schema constraint

It is an error for NOTATION to be used directly in a schema. Only datatypes
that are derived from NOTATION by specifying a value for enumeration can be
used in a schema. Furthermore, the value of all enumeration facets must
match the name of a notation declared in the current schema.

	Reference - http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#NOTATION


* aligned with XML 1.0
* aligned with XML Information Set
* reduces complexity


Regards, Asir S Vedamuthu
-----Original Message-----
From: www-xml-schema-comments-request@w3.org
[mailto:www-xml-schema-comments-request@w3.org]On Behalf Of Asir S
Sent: Friday, November 03, 2000 4:28 PM
To: Biron,Paul V; 'www-xml-schema-comments@w3. org'
Cc: 'Ningang chen'; 'w3c-xml-schema-ig'
Subject: RE: Implementation Experience: Notation is NOT a DERIVED type
of QName

Related POINT -

Drafts say that derived datatypes are those that are defined in terms of
other datatypes: primitive or derived. NOTATION is defined as a derived type
of QName plus the lexical space of NOTATION is the set of all names of
notation declared .. In addition to enforcing the definition of QName, the
processor has to enforce additional constraints that CANNOT BE EXPRESSED

In theory, there should be no difference between the built-in derived
datatypes from CR drafts and user-derived datatypes. Can the end-user define
a datatype that behaves like our NOTATION? NO .. If not, then NOTATION is a
primitive type.

-- Asir
-----Original Message-----
From: w3c-xml-schema-ig-request@w3.org
[mailto:w3c-xml-schema-ig-request@w3.org]On Behalf Of Biron,Paul V
Sent: Friday, November 03, 2000 3:37 PM
To: 'www-xml-schema-comments@w3. org'
Cc: 'Ningang chen'; 'w3c-xml-schema-ig'
Subject: RE: Implementation Experience: Notation is NOT a DERIVED type
of QName

> -----Original Message-----
> From:	ht@cogsci.ed.ac.uk [SMTP:ht@cogsci.ed.ac.uk]
> Sent:	Friday, November 03, 2000 10:06 AM
> To:	asirv@webmethods.com
> Cc:	www-xml-schema-comments@w3. org; Ningang chen; w3c-xml-schema-ig
> Subject:	Re: Implementation Experience: Notation is NOT a DERIVED
> type of QName
> Sorry, I don't agree.  We went through this at the f2f, and agreed
> that _our_ Notations should be named with QNames.  There is no
> connection between them and XML 1.0 Notations.  What specifically do
> you see as the problem with, e.g.
> ... xmlns:po="http://www.example.com/foo" ...
> <simpleType name="myNot">
>  <restriction base='NOTATION'>
>   <enumeration value="po:type"/>
>   <enumeration value="po:code"/>
>  </restriction>
> </simpleType>
> <element name="test">
>  <complexType>
>   <attribute name="foo" type="myNot"/>
>  </complexType>
> </element>
> and an instance
> ... xmlns:po="http://www.example.com/foo" ...
> <test foo="po:code">...</test>
I was also concerned with the design when it was first proposed.  The main
reason was that I saw no way to translate a DTD that had NOTATION
attributes, since in the XML 1.0 + Namespaces world NOTATIONS are not in a
namespace.  However, after a few go-rounds with Henry, we decided that the
current design can work for translating DTDs that use NOTATION
attributes...its not elegant, but it works.

If you need to have a schema that has a target namespace and has NOTATIONS
that are not in any namespace, you just need to have 2 schema documents.
The first one has no target namespace and contains the NOTATION
declarations, the second has a target namespace and imports the first one.

pvblarations, the second has a target namespace and imports the first one.
Received on Monday, 11 December 2000 08:22:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 13 July 2018 09:02:52 UTC