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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: Re: about "prose"


Jacques

It's a question of how complex it should be, I guess. If we want to
support almost every
possibility we can have

<prerequisite id='xyz'>
<prose lan='en'>...</prose>
<prose lan='jp'>...</prose>
<expr name='123'>
<line lan='XPath'>...</line>
<line lan='en'>...</line>
<line lan='jp'>...</line>
</expr>
<expr name='234'>
<line lan='XPath'>...</line>
<line lan='en'>...</line>
<line lan='jp'>...</line>
</expr>
</prerequisite>

I kind of prefer this because it keeps all lines for an expression as
children of the same
parent and with the name attached to the parent, not the children. The
association is
identifiable because the associated lines are bound not just by having
a common name
(which could have unexpected side effects and require rules about
naming scope) but
by having the same parent, which seems a more appropriate use of XML
structuring.

Do we need it to be this complex though? Would automations be able to
support it?
Do predicates need this complexity and power? I guess the principle
might be 'keep
it only just powerful enough and no more complex than such power
requires'. There
would need to be clear rules about not having more than one expr line
with a particular
'lan' value.


Steve


2009/4/15 Jacques R. Durand <JDurand@us.fujitsu.com>:
> Completing the previous proposal:
>
>>For prose information, what would you think about this alternative:
>
> Assuming we can have several expressions inside Predicate / Prerequisite / Target element:
>
> - We could still have a <prose> element associated with Predicate / Prerequisite / Target , and have as many of them as needed for different languages. But each one of these <prose> elements would relate to the entire Predicate (or Prerequisite , or Target), not to a particular sub-expression. The <prose> would explain the entire TA part.
>
> - Now if we want to associate explanation text with a particular <expr> element: we could just use another expression element with same expr/@name that describes what the Xpath expression does (correlation based on the expr @name):
>
> <expr name="abc" lg="Eng" >check the size of the widget</expr>
> <expr name="abc" lg="XPath" >$widget/dimensions/@length le 100</expr>
>
>
>
> -jacques
>
> -----Original Message-----
> From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
> Sent: Tuesday, April 14, 2009 12:22 PM
> To: stephen.green@documentengineeringservices.com
> Cc: TAG TC
> Subject: RE: [tag] a proposal for "multiple" elements in Target, Prerequisite, Predicate
>
> Stephen:
>
> Agree we need to support several languages.
>
> But I don't feel good about having several Predicate elements...
> (although I think it is OK for Prerequisites, as intuitive enough in that case.)
>
> I'd like to stick to the TA guideline as much as possible, which does not have multiple elements for Target, Prereq, Predicate...
> I think the convenience of having fine-grained prose elements is not worth this trouble.
>
> Keep in mind that these multiple elements would not serve your purpose in the following case:
>
> Predicate = (A and B and C ) or (D and E)
>
> Where A,B,C,D,E are expressions that we want to describe separately (<expr lg="XPath">) to manage complexity. In that case you still need an "umbrella" general predicate expression as above. That would be very confusing if you had a predicate element for each one of A,B,C,D,E, then the global predicate expression above as yet another Predicate element. Clearly the implicit AND semantics would not hold.
>
> For prose information, what would you think about this alternative:
>
> - instead of having <prose> elements, just use "English" expression elements that describe what the Xpath expression does (correlation based on the expr @name):
>
> <expr name="abc" lg="English" >
> <expr name="abc" lg="XPath" >
>
>
>
> -jacques
>
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
> Sent: Tuesday, April 14, 2009 6:06 AM
> To: Jacques R. Durand
> Cc: TAG TC
> Subject: Re: [tag] a proposal for "multiple" elements in Target, Prerequisite, Predicate
>
> I'd only add that prerequisite and predicate may need the multiple occurance of the prose sub-element to allow for multiple human languages. The trouble then arises of how to handle both the prose and the expression being multi- occurance. It seems to need the matching of the prose to just or of the 'expr'
> elements or perhaps to the sum expression all of the 'expr' elements. I would prefer to see the 'name' attribute at the 'prerequisite' level:
>
> <prerequisite name="youngauthor">
> <prose lg="en">...</prose>
> <prose lg="fr">...</prose>
> <prose lg="jp">...</prose>
> <expr lg="XPath" > (a boolean expression, e.g. age less
>  35) </expr>
> </prerequisite>
> <prerequisite name="prolific">
> ...
> <prerequisite name="international">
> ...
> <prerequisite name="primary">
> <prose lg="en">...</prose>
> <prose lg="fr">...</prose>
> <prose lg="jp">...</prose>
> <expr lg="XPath"> ( a boolean expression, that states the  overall prereq expression, e.g.: $youngauthor and ($prolific  or  $international) </expr> </prerequisite>
>
> Then it is clear that all of the prose contents for a single prerequisite apply to the same expression.
>
> - Steve
>
> PS: apologies for missing call yesterday - was coming back from holiday and forgot it would mean getting back too late for the call.
>
> 2009/4/10 Jacques R. Durand <JDurand@us.fujitsu.com>:
>>
>> A general proposal for "multiple expressions" in Target, Prerequisite,
>> Predicate:
>> (trying to take into account previous remarks)
>>
>> 1- Target: this element is unique to a TA. But the target may be
>> defined as a composition of several artifacts, that are in turn
>> described by several expressions elements under <target>. It is this
>> composition that is subject to the predicate.
>>
>> See the example given in wiki (issue  #2
>>  http://wiki.oasis-open.org/tag/Issues) , where the target is a
>> combination of "author" + related artifacts, identified using
>> different - but related
>> - XPath expressions :
>>
>> <target>
>> <prose>...</prose>
>> <expr name="author" lg="XPath"
>>>/whoswho/arts[@section="literature"]/biographies/author</expr>
>> <expr name="books" lg="XPath">document(..mybooklist..)/book[@author =
>> $author/name]</expr> <expr name="publishers"
>> lg="XPath">document(..publishing houses ..)
>> /publishersdirectory/publisher[fn:index-of( fn:distinct-values("for
>> $bk in $books return $bk/@publisher"), @name) gt 0 ]</expr> </target>
>>
>> This combination of artifacts is subject to the TA predicate and
>> prerequisite.
>>
>> 2. Prerequisite: this optional element may be multiple in a TA, with
>> the implicit semantics of logical AND.
>> But each one of these <prerequisite> elements is structured like above
>> <target>: MAY contain several named expressions, that may be referred
>> to by their name and composed into more complex logical expressions:
>>
>> <prerequisite>
>> <prose>...</prose>
>> <expr name="youngauthor" lg="XPath" > (a boolean expression, e.g. age
>> less
>> 35) </expr>
>> <expr name="prolific" lg="XPath"> ( a boolean expression, e.g. number
>> books more than 10 over 10 years ) </expr> <expr name="international"
>> lg="XPath"> ( a boolean expression, e.g.
>> published in more than 2 languages )</expr> <expr name="primary"
>> lg="XPath"> ( a boolean expression, that states the overall prereq
>> expression, e.g.: $youngauthor and ($prolific or  $international)
>> </expr> </prerequisite>
>>
>> 3- Predicate: this element is unique to a TA. Structured exactly like
>> a Prerequsite element above.
>>
>> Jacques
>
> ---------------------------------------------------------------------
> 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
>
>


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