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

[Yves Savourel <ysavourel@enlaso.com>]

Hi everyone,

I don't think we decided where to place the re-grouped modules/extension.

Here is the current status:

File:
- modules are between optional <skeleton>/<notes> and <unit>/<group>
- extensions are after the <unit>/<group>
-> should we put the re-grouped modules/extensions before or after the core elements?

Group:
- all after the core elements

Unit:
- all after the core elements

Thanks,
-yves


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

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