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

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

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


Subject: [legalxml-econtracts] RE: JMcClureListingContract.xml


Alexander,

1. I see what you're saying about <TextVersion> now - I had misinterpreted the name. My apologies! "Surely you will agree that just either filtering or translating based on language tag would be silly" -- yes I would, and I agree with you that a container element is absolutely necessary to identify it as a translation, so I do not at all "consider <TextVersion> as a superfluous placeholder". Below, I use the term "Translation":

<foo>
	<en names='Translation.en' class='EnglishTranslation'>
		<en class='Quotation.en'>
		Of two evils, the lesser 
		must always be chosen</en> is the English translation 
		of: <la class='Quotation.la'>De duobus malis, minus est 
		semper eligendum</la>.
	</en>
	<nl names='Translation.nl' class='DutchTranslation'>
		<nl names='Quotation.nl'>
		Van twee kwaden, moet altijd de minste gekozen worden 
		</nl>is de Nederlandse vertaling van 
		<la names='Quotation.la'>De duobus malis, minus 
		est semper eligendum</la>.
	</nl>
</foo>
Please note that I had to put "class" in the markup because IE doesnt yet support CSS selectors based on (namespace-qualified) attributes. In Mozilla, I eliminate the 'class' attribute, and use a CSS selector such as *[names="Translation.nl"] instead. Anyway, with such a class, then the stylesheet changes I mentioned WOULD work I think, albeit the selectors are *.EnglishTranslation and *.DutchTranslation.

As a side note, it could be arranged so as to indicate what is translated.
<foo>
	<en names='Quotation.en'>
		<en names='Translation.en' class='EnglishTranslation>
		Of two evils, the lesser must always be chosen</en>
		<nl names='Translation.nl' class='DutchTranslation'>
		Van twee kwaden, moet altijd de minste gekozen worden</nl>
	</en>
	<en>
		<en names='Translation.en' class='EnglishTranslation'>is the English translation of</en> 
		<nl names='Translation.nl' class='DutchTranslation'>is de Nederlandse vertaling van</nl>
	</en>
	<la class='Quotation.la'>De duobus malis, minus est semper eligendum</la>.
</foo>

2. "You make 'this is English text' the defining feature of the element <en> and 'Seller2LegalName' the value of attribute 'class'. Maybe because you feel that the first concern of every user of your contract XML will be filtering the non-English stuff? 

I spoke above why the 'class' attribute is there. But more to your point: a stream of text is a stream of text first, and then markup is added to it, in this case in the form of the 'names' attribute. In the process, one may need to break that stream of text into smaller pieces, and hence <en> can be a child of <en>. The <en> essentially becomes a "hint" about the document in general, with the semantic work performed by the 'names' attribute. So, filtering for language versions is not done based on the <en> element. The <en> element becomes, at its worst, syntactic sugar that enables multi-model document interchange and, at its best, a statement that the document is fundamentally an English document. Anyway as you know, if it were me writing the stylesheet, I'd not filter the non-English content of the document - I'd just hide it via the CSS stylesheet. Sure I understand that this puts the burden on the server to require the desired document language(s) be specified at the time it is requested - I'd do that via cookies. Failing that, I'd defer to the language in the HTTP header. I guess it depends on the structure of the documents maintained at the server in the final analysis - whether they're stored as one large blob with many translations or not.

3. <usd3> etc - I wrote a memo about my mistake on that one. Should have been <usd.x3>, with "x' being a not-so-sly use of a roman numeral (10*3).

4. "Outside a <en>..</en> block [USD and SQFT] would be meaningless to society at large." - I am not sure what you mean, because if they were meaningless, then they wouldn't be in the text of documents. So they (the acronyms) must be meaningful. In addition, these acronyms ARE standardized by the ISO.

5. "In any text 'USD' will occur in a context, and it will usually not be the most salient feature: it will be a price, or an income etc. What's wrong with <price currency='usd' scale='3'>1</price>?"

Nothing is wrong with it. It's fine for.... internal storage of documents received in public interchange. Remember that my focus is on representing multiple models of the information in documents that are interchanged. This involves assigning names to a string of text, names that say what the text is, including its language, units. and precision. In interchange, it would be expressed as <foo names='Price.usd.x3'>1</foo>. With this, the recipient of the document can turn it into any XML format that they want, ie the format that satisfies their internal coding/template requirements. This reflects my central thesis about public document interchange: have few elements that each carry zero-to-many pointers into one's federated dictionary. To continue with your example, if the 'price' is a 'negotiated price', and that is desired to be so indicated, then one can simply mark it up as <foo names='Price.usd.x3 NegotiatedPrice.usd'>1</foo>.... try doing that! with the conventional architecture which places the entire semantic burden on the names of enclosing or embedded elements and their attributes!

6. Making xml:lang required -- unlikely, that's one reason why <en> and <nl> are compelling to me - noone can then avoid the language axis, or default it.

7. "Uniform markup and a minimal number of different XML elements to understand was also one of the goals of Metalex. You have succeeded better at that goal than we did with your 4 elements!"

Thanks for your comments!
John



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


Powered by eList eXpress LLC