[dsdl-comment] Re: changes to DSRL ?

Martin Bryan wrote:
> David Carlisle wrote:
>
> Agree totally, which is why I am trying to understand what happens in
> various simple cases _without_ refering to annex b. In many cases
> (more or less all cases involving the entity renaming mechanism) the
> prose text leaves the entire process more or less completely
> unspecified. So it would be good to use annex b to at least find out
> what the intended result is, but for a large class of inputs annex b
> gives no result at all.
>
> Annex B used to give all the intermediate stages, but during the
> comments on the final draft it was decided that it should not refer to
> specific processes (which were originally DOM specific) and was
> therefore cut down in size so that there is little or no specific
> guidance in the final text. Not my choice - foisted on me by
> international politics I am afraid
>
> Martin
>>
>>
>> 2008/9/22 Rick Jelliffe <rjelliffe@allette.com.au
>> <mailto:rjelliffe@allette.com.au>>
>>
>> David Carlisle wrote:
>>
>> Rick, Thanks for the feedback. I deleted most of your comments
>> below, but appreciated getting them:-)
>>
>>
>>
>> Rick: xsd:boolean is used in the final. Why not?
>>
>>
>> One may guess that a system should treat additional ="1" the
>> same way as additional="true" but nothing here says that is
>> the case.
>>
>> The schema is normative too.
>>
>> but the schema only says what's allowed it doesn't say what a system
>> is supposed to do.
>>
>>
>>
>> The interpretation rule is that if there are several
>> interpretations that are non-sensical and one that makes sense,
>> then you choose the one that makes sense. The text does not
>> mention additional="false" explicitly, but that does not mean that
>> it does not exist.
>>
>>
>> no extra behaviour is intended for additional="false" so there is no
>> reason to
>> say anything about that. Yes any sane implementor is going to do "the
>> right thing" here so this is only a minor comment, but still I think
>> that if you are going to define things in terns of type checked
>> inputs you should use the language of that typ, not the language of
>> lexical XML syntax. that is, say if the effective value of the
>> additional attribute is true, rather than say if the xml markup is
>> additional="true".
>>
>>
>>
>>
>> Yes that's always the case, but the text does not make this
>> constraint either, so
>> (presumably) a dsrl map that specifies a prefixed name for a
>> PI is a legal DSRL document (but depending on the vaguaries of
>> the implementation) the resulting
>> map may produce documents that are not namespace well formed
>> or produce no document at all (as an xslt implementation may
>> give a compile time error)
>>
>> And errors with the target will be picked up at the time of
>> serialization or XML parsing, depending on the implementation.
>>
>>
>> Serialising what? if there is a compile time error while making an
>> xslt stylesheet out of the dsrl file, then there will never be any
>> generated document in memory to serialize.
>>
>>
>>
>>
>> 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).
>>
>>
>>
>> This implies that there is in fact some output that is not
>> well formed, which could then produce an error message when
>> parsed.
>>
>> Annex b does not constraint implementations. For example, you
>> could have an implementation that converts the DSRL into Perl,
>> and then works by text substitution without ever going through an
>> XML parser or DOM. This is currently allowed, for better or worse.
>>
>>
>> Agree totally, which is why I am trying to understand what happens in
>> various simple cases _without_ refering to annex b. In many cases
>> (more or less all cases involving the entity renaming mechanism) the
>> prose text leaves the entire process more or less completely
>> unspecified. So it would be good to use annex b to at least find out
>> what the intended result is, but for a large class of inputs annex b
>> gives no result at all.
>>
>>
>>
>>
>>
>> If the procedure in annex b is followed this will not be the
>> case, the procedure will produce a fatal error on an
>> intermediate step and no output will be produced. the
>> normative text of the specification never gives any indication
>> that some replacement texts may cause the entire mapping to
>> fail, so I can only assume that annex b is not a correct
>> implementation of the intended process. However I can't guess
>> what the intended process is, so I can not suggest any changes.
>>
>> Annex B does not specify any error issues at all. That does not
>> mean that implementations are not allowed to generate errors, nor
>> that they must.
>>
>> If that is the correct answer (and the text part of the spec
>> would indicate that it is the intended answer) , then as I
>> note above annex b does not implement the defined process (as
>> it will produce no output at all).
>>
>> The defined process does not include any exception handling. It is
>> not complete in the way you expect, and I don't see why it needs
>> to be (nor why it would bad to spell things out more.)
>>
>>
>> It doesn't need to define error/exception processing, which often
>> needs to be handled in a different layer. But I think that the spec
>> does need to be able to say whether things are in error or not.
>>
>> If I define &foo; to have replacement the non-well formed fragment <foo>
>> is that an error or not? I don't expect the spec to say how the error
>> is handled, I do expect it to say whether it as error or not.
>>
>>
>>
>>
>> Cheers
>> Rick jelliffe
>>
>> --
>> DSDL comments
>>
>> To unsubscribe, please send a message with the
>> command "unsubscribe" to dsdl-comment-request@dsdl.org
>> <mailto:dsdl-comment-request@dsdl.org>
>> (mailto:dsdl-comment-request@dsdl.org
>> <mailto:dsdl-comment-request@dsdl.org>?Subject=unsubscribe)
>>
>>
>>
>>
>> --
>> http://dpcarlisle.blogspot.com/
>
>

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