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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Hi all,

Continuing on trying to have validation without using modules references in the core. I've run another experiment:

I've removed all modules references from the core schema, changed the type of validation of the extensions from skip to lax and used
the core, xml, fs, and metadata schemas in the XSD validator I used with Lynx.

That seems to works: each element of the given namespaces are validated against their schemas.
One things that does not get checked is whether or not a module is allowed a given extension point (because that is not in the core
schema anymore).

That I believe could be validated by program, based on the modules' specification that would tell where the elements of the modules
are expected.

I know David that you are worried about not validating all through the schema, but there are other things that cannot be validated
by the schema in some modules. So how will be verify those?

On a side note: FS is now (latest editor's draft) allowed only on elements that allowed extended attributes, except for <ph>, <pc>,
<sc>, and <ec> where the FS attributes and a SLR attributes are allowed but no other non-core attributes are.

I think we should just allow any extended attributes on those elements as well: We should be consistent. If a case was made to allow
FS and SLR there, it means a case could be made to allow other modules attributes in the future. From a core-only processor view
point as soon as you allow a single module somewhere it's the same as making that location an extension point.


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