RE: Informative Text re ambiguity

> From: Harry Halpin [mailto:hhalpin@ibiblio.org] 
> 
> I'm thinking there might be a possibility that the WG would 
> pushback on
> normative text changes, but not informative, yet also the 
> editor will be
> unwilling to cite a TAG unresolved issue in the spec.

That's up to the working group to decide -- not the editor unilaterally.
The spec is a working group product.

> 
> Here's a compromise that uses 'informative text' only to make David's
> point about ambiguity and 'passing the entire representation, not just
> the nodeset which may be ambiguous' to the GRDDL transform. Like all
> compromises, I'm sure it will leave everyone unhappy, but it at least
> flags the issues brought up
> 
> First, after this sentence in the Spec: "Therefore, it is 
> suggested that
> GRDDL transformations be written so that they perform all expected
> pre-processing, including processing of related DTDs, Schemas and
> namespaces. ", it logically follows (since one cannot perform all
> expected pre-processing if one is given, as David Booth pointed out,
> just a nodeset as input to the transform), add that following 
> sentence:
> 
> "In the case where a GRDDL transform specifies all expected
> pre-processing, then the GRDDL transformation language can/should be
> given as input the representation of the GRDDL source 
> document, not the
> node-set derived by the GRDDL-aware agent."

Just as a technical note (not to denigrate this suggestion), this would
be an alternative to proposal 1c (transformation domain).  Like proposal
1c, it represents only a partial solution to the ambiguity problem, as
it does not address ambiguity in the transformation determination step.


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.

Received on Wednesday, 27 June 2007 07:11:27 UTC