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

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

Hi Yves,

I'm quite worried what the consequences of allowing extensions on the inline codes will mean for tool compatibility. We would then have to include how extension namespace attributes should be managed on code cloning and transformation between <pc> and <sc>,<ec> and so on. I doubt that those using extensions there will really conform to our rules on how to modify their extensions.

Regards,
Fredrik Estreen

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: den 3 december 2013 14:52
> To: xliff@lists.oasis-open.org
> 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.
> 
> Cheers,
> -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
>