-----Original Message-----
From: Tony Jewtushenko
[mailto:]
Sent: 20
October 2006 19:39
To: 'Doug Domeny'
Cc: 'Rodolfo M. Raya';
''; 'Asgeir Frimannsson'
Subject: RE: [xliff-comment]
Schema issues with extensible attributes
All:
What is the opinion of the TC on the
“lax” vs. “skip” processing issue? Until
there is some feedback from the TC I will hold off on balloting… If
we’re satisfied with using “skip” I can bundle the schemas
& sample docs together with the spec and set up a ballot. In this
case I would have to revise the spec section on using the XSD’s to
indicate that external schemas are ignored when validating with the
transitional XSD.
If we need further investigation &
discussion it’s worth holding off until we come to a clear
consensus. Either way, please make your views known.
Regards,
Tony
-----Original
Message-----
From: Asgeir Frimannsson
[mailto:]
Sent: 20
October 2006 01:35
To: Doug Domeny
Cc: Tony Jewtushenko; Rodolfo M.
Raya;
Subject: Re: [xliff-comment]
Schema issues with extensible attributes
Doug,
all,
Thank you for the detailed explanations of the XML schema issues, especially
for the clarification on meaning of use='prohibited' .
I am a slightly concerned with changing processContent from 'lax' to 'skip', as
this will not allow us to validate foreign elements/attributes easily. I was
not able to reproduce this bug in xsv (same version as you) or .NET ( 2.0), and
I was not able to find a report or reference to this bug on msdn or google. Can
you share some more information on this?
(after some further testing) It seems that the xsv validator attempts to
resolve the schema location from the namespace name if no schemalocation is
set, ( e.g. if your namespace is http://example.com/example
it will try and load the schema from this location, or if filename-like it will
try and load it as a relative url/file). It is important to note however that
while this is reported in the validator output, it is NOT a validation problem,
as the schema is still reported as valid. If set to 'strict' however, the
missing schema is reported as a validation error, as expected.
cheers,
asgeir
On 10/19/06, Doug Domeny <>
wrote:
Asgeir,
XLIFF TC,
Thanks for pointing out these issues.
Attached are the modified schemas and Sample_AlmostEverything* files. Note
that the files are appended with today's date so that they do not
accidentally overwrite the official copies. Just rename them to remove the
date from the file name.
Asgeir, please test them using your validator(s).
Here's a summary of the changes:
1. Sample_AlmostEverything_1.2_transitional.xlf
1.1 Fixed the file name of the schema by removing the date as pointed out by
Asgeir.
2. Sample_AlmostEverything_1.2_strict.xlf
2.1 Fixed the file name of the schema by removing the date as pointed out by
Asgeir.
2.2 Remove deprecated attributes.
3. xliff-core-1.2-transitional.xsd
3.1 processContents="skip" (was "lax")
The value "lax" is the correct value except that two of the
validators (.NET
XML Parser and XSV 2.10-1) complain that they cannot read the schema. In
short, they treat "lax" the same as "strict". Although I
consider these bugs
in the parsers, it seems better to use "skip" so that all the parsers
I have
(see list below) succeed. Besides, the validation is slightly faster because
it does not need to check for a schema. The only downside is that if a
schema is available for the 'other' namespace, it will be ignored.
3.2 Removed occurrence from xsd:sequence for 'tool' element.
<xsd:element name="tool">
<xsd:complexType
mixed="true">
<xsd:sequence
maxOccurs="unbounded" minOccurs="0">
<xsd:any
maxOccurs="unbounded" minOccurs="0" ...
is now
<xsd:element name="tool">
<xsd:complexType
mixed="true">
<xsd:sequence>
<xsd:any
maxOccurs="unbounded" minOccurs="0" ...
Only one of the validators (Xerces or XSV) complained about the (potential)
ambiguity.
4. xliff-core-1.2-strict.xsd
Same changes as in transitional, plus:
4.1 Removed deprecated attributes. They previously were declared with
use="prohibited".
The use="prohibited" attribute is a bit confusing. As it turns out,
the
standard states that use="prohibited" is only useful when a
definition
inherits from a base definition, such as when adding a restriction. In this
situation, the use="prohibited" may be used to make an optional
attribute in
the base definition invalid. In other words, as if it was not defined. It is
not to be used to explicitly prohibit attributes in a type that allows
xsd:anyAttribute. Oh, well. The validators, however, are not consistent. The
Stylus Studio 2006 and MSXML 4.0 parsers interpret use="prohibit" to
mean
the attribute is invalid. The newer parsers follow the standard and complain
if use="prohibit" is used when there is no base definition. OK, so to
comply
with the standard and newer parsers, we can't define deprecated attributes
with use="prohibited", we must simply not define them and hope the
parser
will treat them as invalid.
4.2 Changed namespace from ##any to ##other to invalidate deprecated
attributes.
<xsd:anyAttribute namespace="##any"
to
<xsd:anyAttribute namespace="##other"
The other half of this change is the namespace for anyAttribute. As Tony
pointed out, the TC chose '##any' to support backward and forward
compatibility. However, W3C XML Schema does not provide a way to override
anyAttribute and explicitly prohibit deprecated attributes, so the namespace
'##other' is needed, as Rodolfo suggested. Since this is only for the
'strict' edition of the XLIFF schema, it should be acceptable.
List of validators I have:
Stylus Studio 2006 built-in
MSXML 4.0 DOM Parser
MSXML 6.0 DOM Parser
Saxonica 8.7 Validator
.NET XML Parser (probably .NET 1.0, but I'm not sure)
Xerces-J 2.5.1
XSV 2.10-1
Regards,
Doug Domeny
Software Analyst
Ektron, Inc.
+1 603 594-0249 x212
http://www.ektron.com
-----Original Message-----
From: Asgeir Frimannsson [mailto: ]
Sent: Tuesday, October 17, 2006 8:13 PM
To:
Subject: [xliff-comment] Schema issues with extensible attributes
Hi all,
I just noticed that the deprecated attributes from 1.1 (eg. ts, tool) are
still being accepted in 1.2 using the strict schema. They are defined with
use="prohibited" in the strict schema. A good example of this is the
example
XLIFF file provided with the specification
(Sample_AlmostEverything_1.2_strict.xlf) - the file still includes all
prohibited attributes, and validates fine with schema validators.
At first I thought this was a bug in the validator I'm using, but then i
noticed how the attribute extension points are defined in the XLIFF schema
(transitional and strict):
<xsd:anyAttribute
namespace="##any" processContents="lax"/>
The XLIFF specification states that "Attributes of a namespace different
than XLIFF can be included in several XLIFF elements". The schema allows
for
attributes of any namespace to be included, including xliff-namespace
attributes not defined in the specification. The schema and specification
are inconsistent here, and it seems the right thing to do would be to change
all anyAttribute elements to:
<xsd:anyAttribute
namespace="##other" processContents="lax"/>
In addition, some issues with the strict sample XLIFF file provided with the
specification:
- schemaLocation points to xliff-core-1.2-strict-20060512.xsd (should point
to xliff-core-1.2-strict.xsd)
- As noted, It still includes the prohibited attributes (eg. tool, ts)
And similar with the transitional sample XLIFF file:
- schemaLocation points to xliff-core-1.2-transitional-20060512.xsd (should
point to xliff-core-1.2-transitional.xsd)
cheers,
asgeir
--
Asgeir Frimannsson
PhD Candidate
School of Software Engineering and Data Communications
Queensland University of Technology
126 Margaret Street, Level 3
Brisbane QLD 4001, Australia
Phone: (+61) 7 3138 9332 Mob: (+61) 405 412 696
Email:
--
Asgeir Frimannsson
PhD Candidate
School of Software Engineering and Data Communications
Queensland University of Technology
126 Margaret Street, Level 3
Brisbane QLD 4001, Australia
Phone: (+61) 7 3138 9332 Mob: (+61) 405 412 696
Email:
