Re: Syntactic sugar for options: a failed experiment?

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

Norman Walsh writes:

> Yesterday, we agreed to allow
>
>   <px:step optname="value"/>
>
> as syntactic sugar for
>
>   <px:step>
>     <p:option name="optname" value="value"/>
>   </px:step>
>
> All well and good, except:
>
>   <px:step ex:optname="foo"/>
>
> doesn't specify the ex:optname option, ex:optname is an extension
> attribute.

Doesn't bother me -- no-one is going to use options in namespaces much.

>  For a different reason,
>
>   <px:step name="foo"/>
>
> doesn't specify the name option, it names the step.

Yes, that's true, but also unlikely to be used much.

> [...] but
>
>   <px:step optname="value">
>     <p:option name="optname" value="value"/>
>   </px:step>
>
> is a syntax error.

Not a mistake anyone is likely to make.

> It's clearly true that is in some sense the shortcuts are easier to
> read, and consequently easier to understand, than the long versions.
>
> But there are a lot of exceptions. Will users find it too confusing?
> I fear they might.

I don't.

> I also fear that we're opening a door here to a lot of requests for
> syntactic sugar. Why not:
>
>   <p:source port="stylesheet" href="someURI"/>
>
> instead of
>
>   <p:source port="stylesheet">
>     <p:document href="someURI"/>
>   </p:sourcE>

We'll just say 'no'.

> Allowing all of the different but obvious shortcuts would make a mess of
> things, I think.

Yes.

> Abort. Abort. Abort. ? :-)

No.  I think section 3.2.1 as written is admirably crisp and
understandable.  Publish the draft, _with revised examples_, and see
what the feedback is.

For example, Ex. 5 looks better:

 Example 5. A Sample Viewport

   <p:viewport match="h:div[@class='chapter']">
     <p:output port="result"/>
     <p:insert at-start="true">
       <p:input port="insertion">
         <p:inline>
           <hr xmlns="http://www.w3.org/1999/xhtml"/>
         </p:inline>
       </p:input>
     </p:insert>
   </p:viewport>

[Note that the prose introducing this example is mistaken -- it should
read

 "A viewport might accept an XHTML document as its input, add an hr
  element at the beginning of all div elements that have the class
  value 'chapter', and return an XHTML document that is the same as
  the original except for that change."
]

In A.1.3 we will have

 <p:error name="bad-document" code="12"
          description="The document element is unknown."/>

[Note there's a well-formedness bug in the generated output, first end
tag is wrong]



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)

iD8DBQFGRHY8kjnJixAXWBoRAiQAAJ9gBpqMuLo3BVZ/v0/qujxhXIoUwACaAx0L
2Gkd2cSG6z5ZBAtCTvUZoYc=
=M3hG
-----END PGP SIGNATURE-----

Received on Friday, 11 May 2007 13:57:20 UTC