dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Issue With Requirement for Trailing Space in class= Values
- From: Eric Sirois <esirois@ca.ibm.com>
- To: Eliot Kimber <ekimber@reallysi.com>
- Date: Mon, 10 Mar 2008 20:05:20 -0400
Hi Eliot,
It looks like the class attributes are
okay as well. The interesting part is that whitespace is also valid
in an xsd:list. It would be interesting to see is that XQuery and
XSLT 2.0 processors deal with the leading and trailing whitespace.
Eric
[1] http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#string
[2] http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#dt-whiteSpace
2.4.2.6 whiteSpace
whiteSpace constrains the value
space of types derived
from string
such that the various behaviors specified in Attribute
Value Normalization in [XML
1.0 Recommendation (Second Edition)] are realized.
The value of whiteSpace must be one of {preserve, replace, collapse}.
preserve
No normalization is done, the value is not changed (this
is the behavior required by [XML
1.0 Recommendation (Second Edition)] for element
content)
replace
All occurrences of #x9 (tab), #xA (linefeed) and #xD (carriage
return) are replaced with #x20 (space)
collapse
After the processing implied by replace, contiguous
sequences of #x20's are collapsed to a single #x20, and leading and trailing
#x20's are removed.
NOTE: The notation #xA used here (and elsewhere
in this specification) represents the Universal Code Set (UCS) code point
hexidecimal A (linefeed),
which is denoted by U+000A in [Unicode3].
This notation is to be distinguished from 
,
which is the XML character
reference to that same UCS code point.
whiteSpace is applicable to all atomic
and list
datatypes. For all atomic
datatypes other than string
(and types derived
by restriction from it) the value of whiteSpace is collapse
and cannot be changed by a schema author; for string
the value of whiteSpace is preserve;
for any type derived
by restriction from string
the value of whiteSpace can be any of the three legal values. For
all datatypes derived
by list
the value of whiteSpace is collapse
and cannot be changed by a schema author. For all datatypes derived
by union
whiteSpace does not apply directly; however, the normalization
behavior of union
types is controlled by the value of whiteSpace on that one of the
memberTypes
against which the union
is successfully validated.
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA Migration and Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue
Pages (Internal)
"Transparency and accessibility requirements dictate that public information
and government
transactions avoid depending on technologies that imply or impose a specific
product or
platform on businesses or citizens" - EU on XML-based office document
formats.
Deborah_Pickett@moldflow.com
03/10/2008 07:44 PM
|
To
| Eliot Kimber <ekimber@reallysi.com>
|
cc
| dita@lists.oasis-open.org
|
Subject
| Re: [dita] Issue With Requirement for
Trailing Space in class= Values |
|
Eliot Kimber <ekimber@reallysi.com> wrote on 08/03/2008 04:42:27
AM:
> In the process of implementing DITA support in our RSuite product,
we
> discovered that the current version of the MarkLogic XML repository
> strips trailing spaces from attribute values. This of course breaks
all
> hope of generic DITA processing unless we implement a workaround in
> advance of MarkLogic fixing their bug (which they might refuse to
fix).
This might not be much comfort, but that behaviour is absolutely in contravention
to the XML spec:
http://www.w3.org/TR/REC-xml/#AVNormalize
(Interpreting the spec: leading and trailing whitespace must be left as-is
if the attribute is declared as CDATA, which DITA @class is.)
> - Does anyone know of any processors that would break if class= had
a
> trailing non-blank character.
DITA-OT's generalization code (generalize-on-conref, as well as the standalone
generalize and respecialize transforms) would probably break. It
breaks the class string into whitespace-separated bits and assumes that
each of them is a doctype/element pair.
--
Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne
Deborah_Pickett@moldflow.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]