[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] RE: [xliff-comment] Section 2.5.4 Validating Documents with Extensions - needs revision
Bryan,
You bring up excellent points. The real problem seems to be with the
implementation of the schema standard. None of the parsers I have correctly
implement "lax". In principle, "lax" is definitely the best choice. In
practice, it's up for grabs.
If we choose "lax" it's not much better than "skip" until the parsers are
fixed. In fact, they currently give a false sense of security.
If we choose "strict" it provides the best protection for determining
whether the XLIFF is truly valid or not. On the downside, it means a person
needs to go through the trouble of making AND DISTRIBUTING a schema if they
wish to use other namespaces and validate their XLIFF. (This applies to me
personally; Ektron uses a proprietary namespace.) It means the strict XLIFF
schema would be very strict.
If we choose "skip" it provides the best chances of avoiding a false
negative due to a missing proprietary schema or defective XML parser.
In the final analysis, we could choose "lax" and let the parsers fall where
they may. Perhaps the Excel table in my previous email could be in an FAQ to
help developers workaround the problems. Personally I prefer "skip" for both
strict and transitional schemas. (Although, for Ektron's purposes, I'll
internally use "strict" during development and debugging because it's best
at detecting defects. I just need to create the proprietary schema.) I
realize this is different from the decision to use "lax" made earlier by the
TC, but I'm concerned with the practical implications. I still agree with
the original decision to use "lax" and would stick by it if the parsers
functioned correctly.
Having said all that, I just realized a serious drawback to using "strict".
Because XLIFF is used as an interchange format (the 'I' in XLIFF), the file
is processed multiple times by various applications and vendors. Using
"strict" would require ALL the vendors to HAVE ALL the proprietary schemas
used within the XLIFF document. Obviously, this is not practical. So I guess
"strict" is not an option.
That leaves us with "lax" and "skip". The .NET parser (and sometimes XSV)
treats "lax" as "strict". So I guess I'm back to (reluctantly) preferring
"skip".
Regardless of which option we pick, as a fall back, the transitional schema
can always be used to determine an acceptable level of XLIFF validity.
Regards,
Doug Domeny
Software Analyst
Ektron, Inc.
+1 603 594-0249 x212
http://www.ektron.com
-----Original Message-----
From: bryan.s.schnabel@exgate.tek.com
[mailto:bryan.s.schnabel@exgate.tek.com]
Sent: Wednesday, October 25, 2006 11:18 AM
To: ddomeny@ektron.com; tony.jewtushenko@productinnovator.com;
asgeirf@gmail.com; xliff@lists.oasis-open.org
Subject: [xliff] RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Hi Doug,
I will check the XSD.
I don't disagree with your recommendation for using strict. But I think it
is worth stating exactly what that means, because it is different than what
we discussed when we chose lax in the first place.
With lax, the parser was obligated to use the schema of the namespaced
elements and attributes to validate them, IF it could find the schema. If
it could not find the schema, it checked the elements and attribute for
well-formed-ness.
By using strict, the parser MUST find the schema for the namespaced elements
and attributes, and the elements and attributes MUST be valid per the spec.
That means if the schema for the namespace elements or attributes ever gets
lost, the XLIFF file CANNOT be valid. It also means if, for example, an
XLIFF document uses an element that is not written as a first child of the
schema element, it could also be invalid.
This is okay by me, but we should all know that this is a much higher
standard than we talked about when we implemented this in the first place.
Thanks,
Bryan
________________________________
From: Doug Domeny [mailto:ddomeny@ektron.com]
Sent: Wed 10/25/2006 7:07 AM
To: Schnabel, Bryan S; tony.jewtushenko@productinnovator.com;
asgeirf@gmail.com; xliff@lists.oasis-open.org
Subject: RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Bryan, et al.,
After analysis, I now recommend processContents="strict" for the strict
schema. All modified files are attached.
strict lax w/ xsd lax w/o xsd
valid invalid valid invalid valid
StylusStudio 2006 correct correct correct valid correct
MSXML 4 DOM correct correct correct valid correct
MSXML 6 DOM correct correct correct valid correct
Saxonica 8.7 correct correct correct valid correct
.NET XML correct correct correct correct error
Xerces-J 2.5.1 correct correct correct valid correct
XSV 2.10-1 correct correct correct valid error?
? if URI returns error 404
As you can see, "lax" for most of the parsers is the same as "skip" and
therefore useless except in .NET parser, which acts like "strict".
The most help comes from using "strict" and providing the schema.
The change is to add the tek schema to documents that use the tek:
namespace.
Sample_AlmostEverything_1.2_strict.xlf
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2"
xmlns:tek="http://www.tektronix.com";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:oasis:names:tc:xliff:document:1.2
xliff-core-1.2-strict.xsd http://www.tektronix.com tektronix.xsd"
version="1.2">
HTML Profile
ExampleXSLTUse_3_BeforeTrans.xlf and ExampleXSLTUse_4_AfterTrans.xlf
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2"
xmlns:tek="http://www.tektronix.com";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:oasis:names:tc:xliff:document:1.2
xliff-core-1.2-strict.xsd http://www.tektronix.com tektronix.xsd"
version="1.2" xml:lang="en-us">
(I also removed the cals: prefix because it is not used.)
Bryan, please check the tektronix.xsd. I renamed it (obviously) and added
attribute definitions for the HTML Profile. Also, soft_sample was removed.
Regards,
Doug Domeny
Software Analyst
Ektron, Inc.
+1 603 594-0249 x212
http://www.ektron.com
-----Original Message-----
From: bryan.s.schnabel@exgate.tek.com
[mailto:bryan.s.schnabel@exgate.tek.com]
Sent: Tuesday, October 24, 2006 6:39 PM
To: tony.jewtushenko@productinnovator.com; ddomeny@ektron.com;
asgeirf@gmail.com; xliff@lists.oasis-open.org
Subject: RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Hi Tony,
Here is a zip file that contains a an example xsd that will serve to
validate the tek: namespace in the sample file. Here are couple of
interesting notes on what I had to do to try to make the tools (that I
have) do their job correctly on this sample:
1. The namespace of the sample schema had to take the unorthodox (but
perfectly valid) step of being the same as the xsd filename:
<xsd:schema xmlns="soft_sample.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; . . .
2. The "Sample_AlmostEverything_1.2_strict.xlf" had to be changed so
that the tek: namespace matched:
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2"
xmlns:tek="soft_sample.xsd"
Even after taking these two brute-force (but perfectly valid) steps my
tools still treated "lax" as if it were "skip". That is, it did not
flag intentional errors I introduced in the tek: namespace of the sample
document (for example, putting an invalid element in the sample, like
<tek:fake_element>The First Volume of Software
Structures</tek:fake_element>).
But to prove that all of the syntax is correct, I changed all of the
processContents="lax" to processContents="strict" in my local copy of
the xliff-core-1.2-strict.xsd schema. This "woke up" my validation
tools so they correctly flagged invalid markup in the tek: namespace.
Note; I included the altered XLIFF strict schema in my zip file, just
for testing purposes (it should not accidentally replace the actual
strict schema).
I guess the bottom line is we're doing our best to write the xsd in such
a way that it will most effectively work with today's
*not-always-compliant* tools to validate documents as we prescribe in
the specification. At the same time, we're doing our best to write the
xsd in such a way that it will also behave correctly with schema
validation tools that actually correctly support the XML Schema spec. As
far as I can tell, the current schema does those two things.
Thanks,
Bryan
-----Original Message-----
From: Tony Jewtushenko [mailto:tony.jewtushenko@productinnovator.com]
Sent: Tuesday, October 24, 2006 1:15 PM
To: Schnabel, Bryan S; ddomeny@ektron.com; asgeirf@gmail.com;
xliff@lists.oasis-open.org
Subject: RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Hi Bryan:
If it's not complicated then I think it's worth waiting an extra few
hours.
If you can send it out by your end of day today I will roll it into a
spec
package tomorrow morning and put together a ballot for it immediately.
Thanks for your work on this.
Regards,
Tony
-----Original Message-----
From: bryan.s.schnabel@exgate.tek.com
[mailto:bryan.s.schnabel@exgate.tek.com]
Sent: 24 October 2006 17:58
To: tony.jewtushenko@productinnovator.com; ddomeny@ektron.com;
asgeirf@gmail.com; xliff-comment@lists.oasis-open.org
Subject: RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Hi Tony,
> Bryan: would it be difficult or too time
> consuming to make the change as
> Doug describes?
This would not be too difficult. But given the fact that I'm on West
Coast US time, and that I will need to work it into my schedule today, I
cannot promise that I would get it done in time for you to roll it into
a 1.2 spec package, and send it out in time for most of our TC to review
it today (i.e., most of our group would *hopefully* be relaxing at home
by the time it gets to be afternoon here in Oregon).
I will work on this today and get it to you as soon as I can. If you'd
rather not wait, and feel you should send out the final revision without
my sample schema, that's completely understandable, and supported by me.
Thanks,
Bryan
-----Original Message-----
From: Tony Jewtushenko [mailto:tony.jewtushenko@productinnovator.com]
Sent: Tuesday, October 24, 2006 6:21 AM
To: 'Doug Domeny'; 'Asgeir Frimannsson';
xliff-comment@lists.oasis-open.org; Schnabel, Bryan S
Subject: RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Doug and all:
At the risk of further delay in the spec, I would prefer using lax for
the
strict schema in order to validate the non-XLIFF content structure
rather
than to validate it is well formed. But it is not a deal breaker for me
and
I would vote to approve the spec & xsd as is (with a couple of small
revisions that I've already made and am ready to send out).
Bryan: would it be difficult or too time consuming to make the change as
Doug describes? If yes, I'll send out the final revision later today
and
set up a ballot. If you provide me with the revisions I can roll them
into
the 1.2 spec package and send it out for review & balloting immediately.
Regards,
Tony
-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com]
Sent: 24 October 2006 13:45
To: 'Asgeir Frimannsson'; 'Tony Jewtushenko';
xliff-comment@lists.oasis-open.org; bryan.s.schnabel@exgate.tek.com
Subject: RE: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions - needs revision
Tony,
I'm fine with changing the 'strict' schema to use "lax" instead of
"skip",
but then we should probably provide the schema for the tek namespace in
the
example.
Bryan, is there a schema or could you create one for the tek namespace
used
in the example?
I'm also fine with leaving both using "skip".
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 24, 2006 1:15 AM
To: Tony Jewtushenko; Doug Domeny; xliff-comment@lists.oasis-open.org
Subject: [xliff-comment] Section 2.5.4 Validating Documents with
Extensions
- needs revision
Tony, Doug, all,
Referring to spec revision 20061023
(http://www.oasis-open.org/archives/xliff/200610/msg00022.html):
"The only change made to the spec was to add a note indicating that
external schema's would not be validated by the Transitional XSD."
Both the transitional AND strict schemas were changed to use
processContents='skip'. I just noticed that this unfortunately also
invalidates section 2.5.4. (Validating Documents with Extensions) of
the specification:
"In order to validate an XLIFF document that contains non-XLIFF parts,
you can use the schema validation mechanism: In addition to the
namespace declarations, add the schemaLocation attribute of the XML
Schema-instance namespace to define what schemas to use to validate
the document (XLIFF and the non-XLIFF namespaces)."
Also note the reference to section 2.5.4 from section 3.1. (XML
Declaration).
If the spec is being updated again as a result of this, also notice
the small insignificant layout-mistake in section 3.1:
"The same example as above would then look like this:<?xml
version="1.0"?>" - the xml declaration should be part of the
following example, and not this paragraph.
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
This publicly archived list offers a means to provide input to the
OASIS XML Localisation Interchange File Format (XLIFF) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: xliff-comment-subscribe@lists.oasis-open.org
Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
List help: xliff-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xliff-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]