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

RE: XMLification of presentation syntax

From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
Date: Fri, 2 May 2008 18:27:21 -0400
Message-ID: <E4D07AB09F5F044299333C8D0FEB45E904FFE02F@nrccenexb1.nrc.ca>
To: Hassan At-Kaci <hak@ilog.com>
Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

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."

I plan to update the XML syntax using entities, as in this example:

"cpt:purchase"^^rif:iri ==> <Const type="&rif;iri">&cpt;purchase</Const>

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>

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.


-----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


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

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

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...



Hassan At-Kaci  *  ILOG, Inc. - Product Division R&D
Received on Friday, 2 May 2008 22:28:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:50 UTC