RE: [xliff] RE: [xliff-inline] Req 1.15 Representation of invalid XML characters

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi Christian,

Is the Inline SC going to define the optional recovery actions for each possible error condition? 

If a document is not valid XLIFF, will readers be forced to fix the errors or will they be allowed to stop processing?

What will happen when a document has an error not contemplated by the specification?

Regards,
Rodolfo
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com


> -----Original Message-----
> From: Lieske, Christian [mailto:christian.lieske@sap.com]
> Sent: Tuesday, September 13, 2011 9:48 AM
> To: xliff@lists.oasis-open.org; Rodolfo M. Raya
> Subject: RE: [xliff] RE: [xliff-inline] Req 1.15 Representation of invalid XML
> characters
> 
> Hi,
> 
> > Some tool vendors may prefer to keep processing until 25 errors are found,
> but that's a developer preference.
> 
> As an alternative, we can - like others - mandate certain behavior in case of
> errors (see e.g. the "static error" in http://www.w3.org/TR/xslt20/#basic-
> conformance).
> 
> Cheers,
> Christian
> 
> -----Original Message-----
> From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
> Sent: Dienstag, 13. September 2011 12:39
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] RE: [xliff-inline] Req 1.15 Representation of invalid XML
> characters
> 
> Hi Yves,
> 
> I think we should not mention anything about further processing once the
> file has been found invalid.
> 
> Some tool vendors may prefer to keep processing until 25 errors are found,
> but that's a developer preference. We can't force anyone to stop processing
> after the first error; similarly, we can't force anyone to keep parsing a file that
> is known to be invalid.
> 
> Regarding the data type for the hex value, if we use "hexBinary" as defined
> at http://www.w3.org/TR/xmlschema-2/#hexBinary, we may need to
> remove the text that says the value can be padded with zeros. It would be
> better to indicate the data type and include a link to the definition. The
> example in the recommendation shows 4 characters representing an hex
> value (0FB7) and when writing the validation expression in the XLIFF schema I
> had to use 4 characters for the minimum value (0000) and 8 for the upper
> limit (0010FFFF) because the editor's parser said that the schema was invalid
> otherwise.
> 
> Regards,
> Rodolfo
> --
> Rodolfo M. Raya   <rmraya@maxprograms.com>
> Maxprograms      http://www.maxprograms.com
> 
> 
> > -----Original Message-----
> > From: Yves Savourel [mailto:ysavourel@enlaso.com]
> > Sent: Monday, September 12, 2011 11:48 PM
> > To: xliff-inline@lists.oasis-open.org
> > Cc: xliff@lists.oasis-open.org
> > Subject: RE: [xliff] RE: [xliff-inline] Req 1.15 Representation of invalid XML
> > characters
> >
> > Hi Rodolfo, Helena, Stevens, all,
> >
> > Thanks for the feedback.
> >
> > To summarize:
> >
> >
> > -- a) Syntax of the hex value:
> >
> > If there is a XSD type we can use, it seems like a good idea to do so. If it
> > allows only upper-case, then so be it.
> >
> > "hex - mandatory. Hexadecimal value of the character's code point.
> > 	The value can be padded with zeros and MUST be in uppercase."
> >
> >
> > -- b) Allowing or not to use cp for characters valid in XML.
> >
> > I would agree with Rodolfo. Being strict is probably better.
> > Thoughts anyone?
> >
> >
> > -- c) Error handling.
> >
> > I understand Rodolfo and Stevens viewpoint: the file should be valid and
> > that's it. No need for expected behavior after that.
> >
> > I was trying to think about the cases where tools want to go beyond the
> error
> > because it's practical: one may want to get a list of the 25 first errors for
> > example and therefore not stop at the first one. Should we care about
> what
> > happened to the data processed after the error?
> >
> >
> > - Writers MUST encode all invalid XML characters of the content using <cp>.
> > - Writers MUST NOT encode valid XML characters of the content using
> <cp>.
> > - Readers MUST process all <cp> elements. (--> not sure if it's needed
> > anymore)
> > - If the value of the hex attribute is invalid, the Readers MUST generate an
> > error.
> > 	- Upon error, Readers MUST consider the whole document invalid,
> > they MAY continue the process only for the purpose of finding additional
> > issues in the document.
> >
> > Or should we just not mention anything about further processing.
> >
> > This case is just one of the error cases we will have to handle in processing
> > expectations, not just for the inline codes. Users expect some possibility of
> > error recovery in tools. Should we provide guidance for that or not?
> >
> > -ys
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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