OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff-comment] Schema issues with extensible attributes


Hi all,

Thank you all again for your insights on this, and I am happy with the
solutions suggested. As Tony points out, a mention in the specification
about this would be good. As long as developers are somewhat aware of this,
if a tool requires lax validation of certain namespaces, it's not
technically difficult to enforce this in a tool-specific way. - But I agree
it's more important to provide a specification that's interoperable and to
get 1.2 out sooner rather than later :)

Regards,
asgeir

On 10/21/06, Doug Domeny <ddomeny@ektron.com> wrote:
>
>  I believe the .NET Parser is exhibiting incorrect behavior because it is
> not "lax" about validating the other namespace. But I spend a good portion
> of my time working around Microsoft bugs. I'm not sure whether the XSV error
> is fatal or just a warning, but given the common use of the .NET parser and
> the error in XSV, I figured it was best to use "skip". I agree the "lax" is
> theoretically the preferred option, but practically the tools don't handle
> it.
>
>
>
> This is the output from the XML parsers that complain about "lax":
>
>
>
> Validating Sample_AlmostEverything_1.2_strict.xlf
>
>
>
> Running custom validation engine .NET XML Parser...
>
>
>
> file:///c:/XLIFF/Specifications/XLIFF 1.2/Sample_AlmostEverything_1.2_strict.xlf:9,5:
> Could not find schema information for the element '
> http://www.tektronix.com:header'.
>
>
>
> -----------------------------------
>
> Validation complete with 1 error(s)
>
>
>
>
>
> Validating ExampleXSLTUse_4_AfterTrans.xlf (from the HTML profile)
>
>
>
> Running custom validation engine .NET XML Parser...
>
>
>
> ExampleXSLTUse_4_AfterTrans.xlf:6,30: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:id'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:6,46: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:title'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:7,48: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:id'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:7,65: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:style'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:17,48: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:id'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:17,64: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:style'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:31,33: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:border'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:31,48: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:cellspacing'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:31,68: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:cellpadding'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:32,33: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:_this'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:87,56: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:name'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:87,70: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:id'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:90,56: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:name'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:90,70: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:id'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:121,36: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:rowspan'.
>
> ExampleXSLTUse_4_AfterTrans.xlf:139,36: Could not find schema information
> for the attribute 'http://www.tektronix.com/TC:colspan'.
>
>
>
> -----------------------------------
>
> Validation complete with 16 error(s)
>
>
>
>
>
>
>
> Running custom validation engine XSV 2.10-1...
>
>
>
> XSV 2.10-1 of 2005/04/22 13:10:49
>
>
>
> Error: can't retrieve "http://www.tek.com/TC": 404 Not found
>
>
>
>
>
>
>
>
>
> Regards,
>
>
>
> Doug Domeny
>
> Software Analyst
>
>
>
> Ektron, Inc.
>
> +1 603 594-0249 x212
>
> http://www.ektron.com
>
>
>   ------------------------------
>
> *From:* Tony Jewtushenko [mailto:tony.jewtushenko@productinnovator.com]
> *Sent:* Friday, October 20, 2006 2:39 PM
> *To:* 'Doug Domeny'
> *Cc:* 'Rodolfo M. Raya'; xliff-comment@lists.oasis-open.org; '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:asgeirf@gmail.com]
> *Sent:* 20 October 2006 01:35
> *To:* Doug Domeny
> *Cc:* Tony Jewtushenko; Rodolfo M. Raya;
> xliff-comment@lists.oasis-open.org
> *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* <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
>



-- 
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]