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 <
ddomeny@ektron.com> 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:asgeirf@gmail.com]
> Sent: Tuesday, October 17, 2006 8:13 PM
> To: xliff-comment@lists.oasis-open.org
> 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: a.frimannsson@qut.edu.au
>
>
>
--
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: a.frimannsson@qut.edu.au