Title: Message
Hi
Tony,
My
opinion is that all things considered, Doug's solution is
best:
<xsd:anyAttribute namespace="##other"
processContents="skip"
In
something of a departure for me, I think from a practical point of view, we want
people to be able to be able to start using XLIFF 1.2 as soon as possible.
Therefore, given the wide range of behaviors by the different validation tools,
Doug's solution causes the least risk of disruption (caused by a tool improperly
implementing the W3C XML Schema standard). I don't think we can be as
prescriptive as we'd like, at this point.
Had I
taken my usual stand, as an XML purist, I would have voted to leave it as
we originally wrote it. As you mentioned earlier, we were very thorough
when we discussed the mechanisms for implementing extensibility for elements and
attributes. We spent a lot of time discussing the differences between the
##any, ##other, ##local, namespace values. We also spent a lot of time
before choosing between lax, skip, and strict processContents values. And,
in theory, I think we got it right (even for today's situation with our strict,
and transitional models). Back then we said
our intent was that the extensibility choices for anyAttribute should be that
any attribute, from any schema (including XLIFF) should be eligible. And
we said that in cases where that schema was available, a validation should take
place. Back then, as I remember it, just a couple of us were doing the
mock-ups and use cases, and test validations. I guess we had the luxury of
doing our tests at a time when there we just a few tools to choose
from to do the validations. At the time XSV
1.2, worked exactly loyal to the spec.
I
totally share Asgeir's concern about not being able to validate namespaced
attributes, but I don't think there's much we can do about it, for
now.
Thanks,
Bryan
-----Original Message-----
From: Tony Jewtushenko
[mailto:]
Sent: Friday,
October 20, 2006 11:42 AM
To:
Subject: [xliff] FW: [xliff-comment]
Schema issues with extensible attributes
-----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:
