RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation

["Tom Comerford" <tom@supratext.com>]

Thanks, Yves. I haven't had much reason to deal with the particular use
case, but it's good to know the authoritative answer. It seems some
less-formal sources of information out there aren't so reliable. Imagine
that.


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com] 
Sent: Thursday, December 05, 2013 02:25 PM
To: 'Tom Comerford'; xliff@lists.oasis-open.org
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle
Attribution) - validation

Hi Tom, all,

I've brought the issue to Felix Sasaki a W3C resource quite familiar with
XML and schema.
He pointed out that the XSD specification seems to indicate this behavior.

[[
I think the issue is that the "lax" option is not defined on a "per schema"
basis but on a "per declaration" basis. See from
http://www.w3.org/TR/xmlschema-1/#Wildcard_details

"lax: If the item has a uniquely determined declaration available, it must
be .valid. with respect to that definition, that is, .validate. 
if you can, don't worry if you can't."

That is, since the validator does not find a declaration for "fs:wrong" in
the schema, it just skips validation.

I assume what you want is: "if in a target namespace no declaration is
given, give me an error". The only way I can see this happen is NVDL.
]]

In other words (if I get it right): lax validates only things for which it
finds a valid definition. Which, in my opinion, is a bit
dumb: If it's marked up as part of a namespace but no definition for it
exist in that namespace the logical thing to do should be to throw an error.
But I guess that's not how lax is defined.

So I think that path is pretty much close.

I've tried the testing with NVDL and it works fine. The problem for NVDL is
that it can't directly test for locations: we can check that fs:fs="bad" and
fs:wrong="value" are both bad, but we can't test hwre they are allowed to
appear. For that we would need an extra part: a set of Schematron rules.
It's doable, but probably not in a short timespan. And there is still all
the constraints and PRs we simply can't test with schema or even Schematron.

So at this point, it seems we could move forward with removing the modules
references from the core, make sure each schema is independent as much as
possible. Validating a file against those will catch already many issues,
and we can code the rest along with the non-schema validation.

Cheers,
-yves


-----Original Message-----
From: Tom Comerford [mailto:tom@supratext.com]
Sent: Wednesday, December 4, 2013 1:32 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle
Attribution) - validation

Yves,

This seems to contradict the XSD specification. With anyAttribute set to
"lax", a bad attribute should throw an error when a schema for the
containing namespace has been found. But as you note, it doesn't.

The common interpretation of "lax" is that it throws no error when the
schema for the namespace is not found, nor when the schema is found but a
definition of the attribute is not part of that schema. It seems to be
commonly accepted (and commonly implemented, as you've seen). If anyone
knows where that detail is hidden in the W3C spec for XSD, I'd like to know.

Tom


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On
Behalf Of Yves Savourel
Sent: Wednesday, December 04, 2013 02:49 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle
Attribution) - validation

More on this attribute validation issue:

If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the
bad attribute fs:badAttr is correctly seen as a bad attribute. If I use
'lax" no error is reported.

I don't understand why: the definition for "lax" is suppose to be "The XML
processor attempts to obtain the schema for the required namespaces and
validate any attribute from those namespaces; however, if the schema cannot
be obtained, no errors will occur."

But this is behaving like if the validators cannot find the schema if the
name of the attribute is incorrect.

BTW: I've also checked that the problem is not coming from my validator: I
get the same behavior in Oxygen when providing the two same schemas with
xsi:schemaLocation.

I'm baffled. Any pointer would be helpful.
-yves


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Wednesday, December 4, 2013 6:56 AM
To: 'xliff@lists.oasis-open.org'
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle
Attribution)

Hi Tom and other schema experts,


I'm trying to implement the validation using a core schema without
reference. And I run into a strange issue for FS:

- the core schema has no reference to FS, just (for example in the <pc>
element):

<xs:anyAttribute namespace="##any" processContents="lax"/>

I load the core and FS schema in the validator and it looks like the FS
schema is used as if I do:

<pc id='1' fs:fs="bad"> I get the expected error about the invalid value.

However if I do:

<pc id='1' fs:badAtt='val'> I don't get an error, while badAttr is not
specified in the FS schema.

Any ideas?
-yves



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php