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

["Lieske, Christian" <christian.lieske@sap.com>]

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