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

Martin Bryan wrote:

>> Page 3, §6.1:
> You draft says that if a content of dsrl:from/dsrl:to contains qualified
> name then that this namespace must be declared on the corresponding
> dsrl:from/dsrl:to element. Why is this? Why it is not allowed to declare
> prefix once on dsrl:maps for example? I think that DSRL should left
> definition of namespace declarations in scope to respective Namespaces
> in XML 1.0 specification (section 6.1 Namespace Scoping).
>
> The problem here is that the names are defined in content. Namespaces do not
> apply to content. There will normally be no elements (or attributes) with
> the relevant namespace declared for use within the map. Even if a prefix in
> the name map is the same as one used to define the map, there is no
> guarantee that the uri being referenced by that prefix is the same. The only
> place that the prefix/uri combinations can be applied is during the
> transformation process. So the transformation process for the specific
> element occurrence needs to know what the uri for the namespace prefix used
> in the content. It is arguable whether or not the name should be declared as
> a local namespace, rather than as just a simple namespace attribute as Rick
> suggested, but I decided that we should not introduce Yet Another Way Of
> Declaring Namespaces when all that was needed was to pick up the local
> declarations of namespace prefixes.

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.

>> To summarize my comments to entities: The current proposal is far from
> being useful. Because:
>
>> 1. Doesn't allow references between entities
>
> The infinite renaming of nested entities is just too complicated for DSRL,
> which is just a simple form of transformation. Even XSLT patterns do not
> allow entity mapping to be done. Sorry, but I rejected this idea because I
> could not implement it, most other developers would have trouble
> implementing it and there is a restriction on me that I can't publish the
> standard until there is at least one implementation (and I have to publish
> it in a 4 year timescale!!!!)

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.

>> 2. Markup inside replacement text is escaped -- so it is not markup
> anymore and can't be processed without reparsing as a separate document
>
> Again this was deliberate. The idea is to produce a renamed document that
> can be reparsed against an alternative schema. The renamed entities are
> deemed to be part of that schema. Their replacement text cannot be invoked
> until the renamed instance is parsed agains the target schema.

Sorry, but I don't understand what you are trying to say here.

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.

>> 3. Mechanism for attaching entity definitions to document instance is
> not defined.
>
> There is deliberately no standarized way for doing this because there is no
> way of detecting which form of schema will be used to validate the output
> document.

But declaration of entities and validation are two completely different
tasks (which are unfortunately syntactically mixed in DTDs). 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.

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO/JTC1/SC34 member
------------------------------------------------------------------
 Want to speak at XML Prague 2007 => http://xmlprague.cz/cfp.html

--
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)