W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2008

Re: XMLification of presentation syntax

From: Hassan At-Kaci <hak@ilog.com>
Date: Fri, 02 May 2008 18:28:25 -0700
Message-ID: <481BBFB9.9020300@ilog.com>
To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Boley, Harold wrote:
> Given an entity declaration
> (http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-entity-decl),
> 
> say
> 
> <!ENTITY rif "http://www.w3.org/2007/rif#">
> 
> we can use an entity reference
> (http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-references),
> 
> say
> 
> &rif;
> 
> so that, e.g.,
> 
> <Const type="&rif;iri">
> 
> stands for
> 
> <Const type="http://www.w3.org/2007/rif#iri">.
>  
> -- Harold

Hmmm... This is then different than what is in the latest BLD draft...
Note that his makes XML serialization look quite different than what can
be seen therein. Has this been discussed anywhere? If so when? (I  would
then have missed it!) The last I recall (and in the latest BLD draft) we
still had things like "rif:iri" not "&rif;iri". Not that I mind one way
or the other (besides matters of taste/style), but could you please fill
me in on why one rather than the other? (In the current implementation I
am playing with I serialize such a  Const as follows:

       <Const typespace="rif" typename="iri">

which I find clearer and less arcane. But this is my taste. I can surely
make it produce your entity-style notation if this is what this group
prefers.)

-hak

> -----Original Message-----
> From: Hassan At-Kaci [mailto:hak@ilog.com] 
> Sent: May 2, 2008 8:47 PM
> To: Boley, Harold
> Cc: Public-Rif-Wg (E-mail)
> Subject: Re: XMLification of presentation syntax
> 
> Boley, Harold wrote:
>> Hi Hassan,
>>
>> Good to learn about your progress here, which should help soon in
>> the development of test cases etc.
>>
>> There is this Resolution from F2F7:
>> "RESOLVED: In the XML syntax, we'll use full IRIs (not qnames or
>> curies) for Const types, etc. Of course, XML entities can be used."
>> http://www.w3.org/2005/rules/wiki/Resolutions
>>
>> I plan to update the XML syntax using entities, as in this example:
>>
>> "cpt:purchase"^^rif:iri ==> <Const type="&rif;iri">&cpt;purchase</Const>
> 
> Huh? Could you pls kindly comment on the &rif; and  &cpt; thingies?
> 
>> cpt:purchase and rif:iri are tokenized as pairs of atomic strings
>> (e.g., the pairs colon('cpt','purchase') and colon('rif','iri'),
>> respectively), from which the XML is ultimately generated.
>>
>> Generally, for a single colon on both sides of the doublehat:
>>
>> "w:x"^^y:z  =tokenize=>  doublehat(colon('w','x'),colon('y','z'))
>>               . . .
>>             =xmlgen=>    <Const type="&y;z">&w;x</Const>
> 
> Same question re: &y; and  &w; ...
> 
> Thanks.
> 
> -hak
> 
>> We could forbid multiple colons on either side of the doublehat
>> or adopt an appropriate escaping convention for colons, hats, etc.
>> In case there is no colon on either side of the doublehat,
>> tokenizing of that side returns a single atomic string.
>>
>> Best,
>> Harold
>>
>>
>> -----Original Message-----
>> From: Hassan At-Kaci [mailto:hak@ilog.com] 
>> Sent: May 2, 2008 1:39 PM
>> To: Boley, Harold
>> Cc: Public-Rif-Wg (E-mail)
>> Subject: XMLification of presentation syntax
>>
>> Hi,
>>
>> While this ping-pong exchange has been raging on the topic of the -
>> by now - (in)famous, notation "foo:bar"^^rif:buzz, I have been myself
>> laboring on more pedestrian pursuits generating a compiler for the
>> presentation syntax that would at least be able to parse the syntax
>> of the examples given in [1] and produce the XML trees rendered as
>> written by you in that document.
>>
>> Here is what I am not sure to understand right. Your explanation
>> will be most appreciated - so I can proceed and finish that thing
>> already!... :-) (I am very close actually - but I'd be unwise to
>> crow victory too soon as there may be further such snags lurking
>> still.)
>>
>> The EBNF rules you give for this pertain to the non-terminal Const
>> for which you give the following rules (in [2]):
>>
>>    Const          ::= '"' UNICODESTRING '"^^' SYMSPACE
>>    SYMSPACE       ::= UNICODESTRING
>>
>> Then, you give the following (informal context-sensitive) translation
>> (meta-)rule for expressing this construct in XML (see [3]):
>>
>>    unicodestring^^space ==> <Const type="space">unicodestring</Const>
>>
>> Note that this EBNF uses two tokens '"' and '"^^' and NOT three tokens
>> '"', '"', and '^^', so that this begs the question of how what goes in
>> between '"' and '"^^' gets interpreted (especially ':').
>>
>> You give examples of how this is actually used to produce the XML
>> encoding of the presentation syntax, such as in Example 4 of [4] :
>>
>>    "cpt:purchase"^^rif:iri ==> <Const type="rif:iri">cpt:purchase</Const>
>>
>> Now, I note the following points in this example:
>>
>> a. cpt:purchase (without quotes) is the UNICODESTRING. By that, I
>>     understand that it is tokenized as a single atomic string (namely,
>>     the string 'cpt:purchase' where ':' is part of the string).
>>
>> b. rif:iri (also without quotes) is also a UNICODESTRING, and thus
>>     it too is tokenized as a single atomic string.
>>
>> The above makes me think that the UNICODESTRING could be anything
>> not containing special chars (including ':' and such that may have
>> other special meaning in XML). Am I right ?
>>
>> My question: "Is ':' given any special meaning? In other words, is
>> 'cpt:purchase' an XML local name, or is it that 'cpt' is the XML
>> namespace and 'purchase' the XML local name ?
>>
>> Thanks for clarifying...
>>
>> -hak
>>
>> References:
>>
>> [1]http://www.w3.org/2005/rules/wiki/BLD
>> [2]http://www.w3.org/2005/rules/wiki/BLD#EBNF_for_the_RIF-BLD_Rule_Language
>> [3]http://www.w3.org/2005/rules/wiki/BLD#Translation_of_the_RIF-BLD_Condition_Language
>> [4]http://www.w3.org/2005/rules/wiki/BLD#XML_for_the_RIF-BLD_Condition_Language
> 
> 


-- 
Hassan At-Kaci  *  ILOG, Inc. - Product Division R&D
http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
Received on Saturday, 3 May 2008 01:28:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:48 GMT