[dsdl-comment] Comments on part 8 (DSRL)

From: David Carlisle <davidc@nag.co.uk>
Date: Wed Jan 09 2008 - 10:46:50 UTC

Some comments on (what I hope is) the current draft of part 8.




If the content is a namespace-qualified name, the namespace used
should be declared in a namespace declaration that is declared as an
attribute of the dsrl:from element.

"should" here is unclear. What happens if the declaration is elsewhere
(on an ancestor) is that legal? A following NOTE claims that
restricting the location of the namespace declaration "may make
processing easier" but it is very hard to ensure if the file is
generated by many namespace aware technologies especially XSLT,
where you have no direct control over the location of namespace
declarations, a system will not insert redundant declarations if this
namespace is already in scope.

Matching is defined in terms of XPath "patterns" but XPath defines
expressions not patterns, I think(?) XSLT patterns are meant here but
I'm not sure. (XSLT Patterns have a more restricted syntax than Xpath

The NOTE says that this allows the "default XSLT rule" of using the
last matching template, but this is an _error recovery_ in XSLT,
having duplicate matches is an error and a processor may stop and
produce no output, using the last matching template is an optional
recovery action, not a "default rule".

Names are described as being (or not being) namespace qualified
but I think Xpath names are always namespace qualified, although they
may be unprefixed (and in that case may be bound to no-namepsace)
I think "namespace qualified" here is being used to mean "prefixed" in
which case it isn't clear if the default namespace xmlns=... may be
used. However it would be best to change the wording to "prefixed" if
that is what is meant.

Here and elsewhere dsrl:from is restriced by the text of the
specification to have content an XML Name, but the Relax schema gives
it content model text not xsd:Name, why this difference? I could
understand it if XSD types were being avoided everywhere but
xsd:boolean and xsd:QName are used elsewhere in the schema.

Is xsd:boolean the intended datatype (allowing 0 and 1 as well as true
and false) for boolean attributes such as additional="0" ?.

You may want to restrict the names to NCNames in no-namespace (for
both source and target PI names (as otherwise the document is not
namespace well formed)

I think that the entity mechanisms should be dropped they are under
specified and can not work in many contexts.

If renaming is going to be allowed, as for PIs you probably want to
restrict to NCNames in no namespace.

The suggested mechanism for implementing this of changing
&foo; to
[[entity foo]]
then doing the renaming and finally restoring the entity syntax will
fail if the replacement text of foo includes elements that need to be
renamed. The element (and attribute and PI) renaming has to see the
documents with entities expanded so that the correct context for
patterns can be constructed.
All the examples (in this document and the associated tutorial avoid
this problem).

Given a document
<!ENTITY y "<y/>">

what is the result of a DSRL map that maps the element name y to the
name z, and the entity name y to the entity name z?

As for section 6.7 I think this should be dropped, however assuming it
isn't dropped, there are some points that would seem to need

There doesn't appear to be any restriction that the replaceent text be
well formed. Markup is quoted with CDATA


causes the replacement text to be the element <foo/>

<dsrl:replacement-text><[CDATA[ a < b]]></dsrl:replacement-text>

define an entity that has replacement text that is not well formed.
It is not possible to define such an entity using XML DTD, so not
possible to convert these "entities" to standard XML entities.

It should be an error if the replacemnet text was not well formed, this
would be much easier to ensure if there was no requirement to CDATA
quote markup.

The current text seems inconsistent: the prose text says that markup
must be quoted and gives the example

<![CDATA[the W3C Extensible Markup Language (<acronym>XML</acronym>)]]>

However the content model is defined as any-content not text,

define replacement-text = element dsrl:replacement-text {any-content}

so the more natural

 the W3C Extensible Markup Language (<acronym>XML</acronym>)

is also valid (but what replacement does it produce?)

similarly if the markup in the example in the draft produces an
acronym element in the result document, what does

<![CDATA[the W3C Extensible Markup Language (<acronym>XML)]]>


appendix B
particularly application --> particular application

DSDL comments
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-comment-request@dsdl.org
Received on Wed Jan 9 11:47:18 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 09 2008 - 16:33:02 UTC