[dsdl-discuss] Re: FDIS for Part 8]

Jirka wrote:

>Yes, I agree that we should not introduce any new way for declaring
namespaces. But this is inconsistent with the current draft, because it
changes how namespace declarations in scope for dsrl:from/dsrl:to are
calculated. According XML namespaces namespace declarations are
inherited to all descendant elements (if not overwritten), but you are
considering only declarations present directly on dsrl:from/dsrl:to
element. This is not only inconsistent, but it also makes DSRL harder to
implement, because some XML data models or APIs are not exposing
namespace declarations literally, they are exposing view of XML document
where namespace declarations are already inherited. In this case you
can't distinguish situation where namespace was declared directly on
dsrl:from/dsrl:to from situation where namespace was declared on
ancestor of this element.

Agreed, this is a problem with my approach. But if the namespace is declared locally at least the right URL should be present. The problem is how to validate that the definition has been obtained from the local element.

>I was not talking about entity renaming, but about defining entities
(section 7 in the draft). IMHO it would be better to remove this feature
completely then provide it in a shape which is less powerful then
mechanism provided by XML itself.

This has been discussed in the committee, who felt that an XML methodology for defining entities would be advantageous to DSDL.
Makoto has suggested that an option would to make the entity map and entity definitions optional features of DSRL. Would this meet your objection?

>Escaping of XML markup is bad in general (e.g. see
http://norman.walsh.name/2003/09/18/unescmarkup) and I don't see any
reason why using it in DSRL will bring benefits.

Agreed it is bad, but in this case the only way I could find of allowing entity references within replacement text was to escape all markup within replacement text data defined within the map. The alternative of using a model of ANY just gave too many problems at the processing stage.

The suggestion that:
>DSRL could define for example processing instruction which can be used by DSRL conforming XML parser to load and expand entities before further processing (e.g. validation) starts.

was considered but rejected as PIs cannot be processed using XSLT.

Martin

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)