W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2007

Re: standard components edits

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 16 Apr 2007 10:25:30 +0100
To: "Alex Milowski" <alex@milowski.org>
Cc: public-xml-processing-model-wg@w3.org
Message-ID: <f5by7ksk6wl.fsf@hildegard.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Milowski writes:

> On 4/13/07, Innovimax SARL <innovimax@gmail.com> wrote:
>>
>>
>> > I propose that we add an optional "p:load-relax-ng" step that takes no
>> > inputs, a required "uri" option, and outputs a RELAX NG grammar. It
>> > should be spec'd to say that it can load either the compact syntax or
>> > the full syntax.
>> >
>> > Otherwise, I think we wind up needing co-constraints on the
>> > validate-relax-ng step that I'd as soon avoid.
>>
>> Ok but if we want to stay consistent we should have the same for XQuery
>> ...
>
>
>
> I don't think we can do the exactly same for XQuery.  There isn't a standard
> transliteration of
> a XQuery into XML.
>
> We could read in the non-XML syntax XQuery and wrap it with the 'query'
> wrapper
> but I'm not certain we want to do that.
>
> Personally, I'd prefer that we not do either.  You can't read other non-XML
> sources unless
> you have a special component.  Now we're added one for Relax, next XQuery,
> and then ... ?

I strongly agree -- no special-casing for N3 or Relax-NG or XQuery or . . .

I note that we can get an arbitrary text document into a pipe with a
trivial wrapper element as follows

 <p:xinclude>
  <p:input port="source">
   <p:inline>
    <wrapper>
     <xi:include href="[your doc URI here]" parse="text"/>
    </wrapper>
   </p:inline>
  </p:input>
 </p:xinclude>

Should we provide a micro-component for this case, e.g.

 <p:wrapped-text href="[anyURI]" wrapper="[QName]"/>

?

We could then say that compact syntax for RelaxNG or XQuery query docs
must be wrapped in specified elements, and then their secondary inputs
are to a limited extent polymorphic, distinguished by their document
elements, as between full/compact for Relax-NG and XQueryX/text for
XQuery.

I also don't think I care as much as Norm does about co-constraints,
so I'm perfectly happy if we give e.g. our Relax-NG component two
secondary inputs only one of which should get input in any given pipe
- -- what happens if both are connected is implementation-determined.

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFGI0EKkjnJixAXWBoRApH5AJ9rsE2rte47f14MUhRXq146iVk/1gCfZM8e
+9LSRtYC5/b/DcO7aNoIFU4=
=WDdO
-----END PGP SIGNATURE-----
Received on Monday, 16 April 2007 09:25:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:50 GMT