[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation
Hi Yves, all, I think the modules and extensions should go before the <unit> and <group> elements on all levels. It would be consistent and it would allow stream processing of <unit>s regardless of how the grouping around them looks. If they should go before skeleton / notes I don't have any opinion on. Regards, Fredrik Estreen > -----Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf > Of Yves Savourel > Sent: den 6 december 2013 13:47 > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - validation > > 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 > > > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]