Hi Christian, >> ...have only a unique <ph> element with an optional >> attribute that would indicate whether it represents a >> start, end or placeholder code... >
> To my ears, the work with just one representation
> sounds attractive. Before we even get to discuss a single element representation :) we would have to first contemplate the elimination of the <pc> representation. I'm curious about the opinion of everyone. I'm guessing Bryan is very much in favor of having it. (and it is in the list of requirements). What about others? <sc>/<ec> alone or both <sc>/<ec> and <pc>? Here is a rough list of pros-cons I can thing of: Pro of eliminating <pc>: - It simplifies the implementation to a great extend: No need to find out if the code has a corresponding opening/closing in the same segment. - it reduces our list of attributes, getting rid of all the ...Start and ...End like equivStart/equivEnd. So it's a bit simpler to write/read and implement. Cons of eliminating <pc>: - we don't implement the requirement 17 (should preserve span-like structurs ( http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#Shouldpreservespan-likestructures ) - it may makes life more complicated for XSLT-based processor. (...Although I'm not 100% sure about this. Because having <pc> does not eliminate <sc>/<ec> since you can have span split by segments. So presumably XSLT-based tools will have to deal with <sc>/<ec> anyway).
More pros/cons anyone? Cheers, -ys
