Re: XSLT Literal Result Element

"Rhys Lewis" <rhys.lewis@volantis.com> writes:

> First, thanks very much for taking the time to comment on the last call working draft of Content Selection for Device Independence.

You're welcome!

> froumentin-1:
> ------------------
> "The functions could be defined in the same style as the XPath2/XQuery Functions and Operators spec [2], i.e. make them namespaced? "di-cssmq-width" -> "sel:cssmq-width". That would allow XPath2 engines to use the functions without any ambiguity about where they come from."
>
> Response:
> ---------------
> DIWG has decided to decline this comment.
>
> We've debated the question of using XPath 2 or XPath 1 on many occasions during the development of the specification. Indeed we have even had internal versions that were based on XPath 2. We would have preferred to allow the host language to decide which version of XPath it preferred to use. Comments on an earlier working draft showed that that was, unfortunately, disallowed.
>
> In the end there were two reasons for sticking with XPath 1, despite the advantages of namespace support and data typing offered in XPath 2. The first was the availability of implementations. This is particularly important where the specification is implemented on client mobile devices. The second was compatibility with XForms. Although not apparent from the specification alone, DISelect forms part of a language profile being developed by DIWG. This profile depends on XHTML 2 and XForms, so compatibility is important for the DI group's use of the specification.


It's not so much a question of XPath2 vs XPath1. I guess the way my
comment was written was misleading.  But in fact, when you look at
XSLT1, it adds functions to XPath1 in two ways:

1. it adds non-namespaced functions to the XPath functions,
  e.g. document(), key() just like DISelect
  does. <http://www.w3.org/TR/xslt#add-func>

2. it allows the stylesheet writer to define their own function in their own
  namespace. <http://www.w3.org/TR/xslt#section-Extension-Functions>

Pros of 1.
- no extra namespace declaration required

Pros of 2.
- can dereference the namespace uri to fetch a normative description of the function
- avoids name collisions with any other functions the author would use
- works better with Xpath2 (should you ever require it), but does not mandate it.

as for the syntax, "di-cssmq-width" vs "di:cssmq-width". Same thing.

I slightly prefer 2, and the WG's argument for 1 doesn't convince
me, yet. So I guess I'm not yet satisfied with the resolution.

> froumentin-1:
> ------------------
> " There are many typos in the spec, mostly missing spaces following code or anchor tag."
>
> Response:
> ---------------
> DIWG has decided to accept this comment.
>
> We will review and correct the formatting of the entire document. Thanks for pointing this out.

I'm satisfied (although I'll have to check the next draft, I suppose)

> froumentin-3:
> ------------------
> "Section 5 is confusing because one doesn't know the structure of each element until 5.10. I would suggest examples in each section. Or even better, something like:
>
>    5.1 Overview
>    5.2 Conditional Processing
>      5.2.1 if
>      5.2.2 select (describe when/otherwise here)
>    5.3 Options
>      5.3.1 idreplace
>      5.3.2 process
>      5.3.3 required"
>
> Response:
> ---------------
> DIWG has decided to accept this comment.
>
> The primary issue is that the internal structure of the <select> element is not apparent at the start of section 5. While we accept that there can be an improvement here we would prefer that all of the elements be defined in sections that appear at the same nesting level in the TOC to make them easy to spot.


But the elements are at the same level in my proposal above...

>
> Rather than reorganising the section, we will add an introductory description of the structure of the elements and describe their typical use in the Overview section (5.1). 

I guess I'll hold my satisfiedness until I've read the next draft.

Cheers,

Max.

Received on Friday, 13 May 2005 14:53:08 UTC