[dsdl-comment] Re: changes to DSRL ?

Martin Bryan wrote:
> David/Rick
>
> Thanks for answering David's questions now I am no longer generally
> available Rick. Once comment though:
>
> Re:
> <dsrl:replacement-text>
> <![CDATA[the W3C Extensible Markup Language (<acronym>XML</acronym>)]]>
> </dsrl:replacement-text>
>
> However the content model is defined as any-content not text,
>
> define replacement-text = element dsrl:replacement-text {any-content}
>
> Rick: Yes, I think this is misleading, though not wrong in the sense
> of generate false negative
> validation results.
>
> Martin: It is not misleading it is essential for the example, where
> there is markup in the replacement text. I don't think text allows for
> the CDATA markup needed for mixed text, and certainly would not be
> appropriate if the replacement text was simply acronym>XML</acronym>
>
> Martin
>
> Rick Jelliffe wrote:
>> David Carlisle wrote:
>>>
>>> Since that is a password protected page, could anyone comment if any
>>> of the items in
>>>
>>> http://lists.dsdl.org/dsdl-comment/2008-01/0004.html
>>>
>>> have been addressed?
>> David:
>>
>> 6.1
>>
>> 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?
>>
>> Rick: Yes. The text is now
>> "The name of the element to be mapped is recorded in the content of
>> the dsrl:from element. This content shall be
>> a valid XML name, which can include a prefix that identifies the
>> appropriate namespace. If the content is a prefixed
>> name, it is recommended that the prefix used be declared in a
>> namespace declaration that is declared as an attribute
>> of the dsrl:from element."
>>
>> I would prefer MAY language rather than "can" and "it is recomended",
>> but it does not change anything. The point
>> of this is that for simple cut and paste, or for simple inclusion
>> references, a document known to have the prefixes
>> defined on the current element will be easier for editing.
>>
>>
>> David: 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
>> expressions).
>>
>> Rick. Yes, the text now uses XSLT patterns.
>>
>> David: 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".
>>
>> Rick: This note is still there, and should be corrected.
>>
>> David: Names are described as being (or not being) namespace qualified
>> but I think Xpath names are always namespace qualified, ...
>> it would be best to change the wording to "prefixed" if
>> that is what is meant.
>>
>> Rick: I think this has been done:
>> "The name of the element to be mapped is recorded in the content of
>> the dsrl:from element. This content shall be
>> a valid XML name, which can include a prefix that identifies the
>> appropriate namespace. If the content is a prefixed
>> name, it is recommended that the prefix used be declared in a
>> namespace declaration that is declared as an attribute
>> of the dsrl:from element."
>>
>> However there is still
>> "Names can be qualified providing the relevant namespace prefixes
>> have been declared within the map. They cannot
>> contain spaces, or any other character that is not a valid name
>> character as defined in the W3C XML specification."
>>
>> David: 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.
>>
>> Rick: <text> is still used. Perhaps it avoids the XML 1.0 or XML 1.1
>> issue.
>>
>> David: Is xsd:boolean the intended datatype (allowing 0 and 1 as well
>> as true
>> and false) for boolean attributes such as additional="0" ?.
>>
>> Rick: xsd:boolean is used in the final. Why not?
>>
>> David: 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)
>>
>> Rick: The schema does not validate every constraint it could.
>>
>> David:
>>
>> Given a document
>> <!DOCTYPE y [
>> <!ENTITY y "<y/>">
>> ]>
>> <y>
>> <y/>
>> &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?
>>
>> Rick: (David and I have been discussing this, with me getting it
>> wrong.) The first step is the entity remapping
>> step, according to Annex B.
>> <!DOCTYPE y [
>> <!ENTITY z "<y/>">
>> ]>
>> <y>
>> <y/>
>> &z;
>> </y>
>>
>> The second step is to apply the remappings. Parsing the XML document
>> necessarily involves dereferencing internal general entities. So this
>> gives,
>> in effect, the document
>>
>> <y>
>> <y/>
>> <y/>
>> </y>
>> which is then remapped to give
>> <z>
>> <z/>
>> <z/>
>> </z>
>>
>> In appendix B, it speaks of an XSLT 2 transform over a DOM obect. I
>> think the DOM is used
>> merely to show that an implementation may preserve entity boundary
>> information, in which case
>> the original document could be reserialized as
>> <!DOCTYPE z [
>> <!ENTITY z "<z/>">
>> ]>
>> <z>
>> <z/>
>> &z;
>> </z>
>>
>> Furthermore, because of XML's WF entity rules, an implementation
>> could also
>> merely apply remapping to the internal entity text without expanding
>> the entities.
>>
>> All that said, I think David is right that it would be good to spell
>> this all out in the
>> normative text better.
>>
>> David: There doesn't appear to be any restriction that the replaceent
>> text be
>> well formed.
>>
>> Rick. Yes. The error will be reported by the XML parser, it is not a
>> requirement
>> that the DSRL converter reports it (though it may, as an XML not a
>> DSRL error).
>>
>> David: 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.
>>
>> Rick: But then you would have to deal with serialization back to
>> entity text of the
>> parsed XML.
>>
>> David:
>>
>> <dsrl:replacement-text>
>> <![CDATA[the W3C Extensible Markup Language (<acronym>XML</acronym>)]]>
>> </dsrl:replacement-text>
>>
>> However the content model is defined as any-content not text,
>>
>> define replacement-text = element dsrl:replacement-text {any-content}
>>
>> Rick: Yes, I think this is misleading, though not wrong in the sense
>> of generate false negative
>> validation results.
>>
>> David: what does
>>
>> <dsrl:replacement-text>
>> <![CDATA[the W3C Extensible Markup Language (<acronym>XML)]]>
>> </dsrl:replacement-text>
>>
>> produce?
>>
>> Rick: A non-WF XML document.
>>
>> David: appendix B
>> particularly application --> particular application
>>
>> Rick: Fixed.
>>
>> Cheers
>> Rick
>>
>>
>>
>> --
>> DSDL comments
>>
>> To unsubscribe, please send a message with the
>> command "unsubscribe" to dsdl-comment-request@dsdl.org
>> (mailto:dsdl-comment-request@dsdl.org?Subject=unsubscribe)
>>
>>
>
>

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