[dsdl-discuss] Re: Emailing: dsdl-8.pdf

It seems we cannot get consensus on this issue, so Part 8 must be abandoned.

I want a standard that allows everything that has a "name" as defined in XML to be renamable.

There seem to be too many objections to the renaming of entity references to make this achievable.

Therefore I can see no option but to abandon the whole concept on name mapping.

Martin
  ----- Original Message -----
  From: MURATA Makoto
  To: dsdl-discuss@dsdl.org
  Sent: Tuesday, May 01, 2007 3:37 AM
  Subject: [dsdl-discuss] Re: Emailing: dsdl-8.pdf

> Murata-san
>
> >I am very confused. First, can entity renaming as specified in Part8
> handle renaming of unparsed entities? This should be very clearly
> stated. If it is covered, the definition in 3.2 is confusing, since
> it says "general".
>
> Good hit. I had not reviewed the definition there in the light of the switch
> to DOM. The restriction has been removed.

  It is now clear that you intend to take unparsed entities into
  consideration. However, entity definitions as shown in Section 7
  can handle parsed entities only. Moreover, are attribute values
  renamed by DSRL when they are defined to be names of unparsed entities?

> >> The XDM model specifically states:
> >> Because the data model requires that all general entities be expanded,
> there
> >> will never be unexpanded entity reference information item children.
>
> >> Therefore XDM cannot be used as the data model for DSRL processing any
> more
> >> than the XML Information Set can.
>
> >Please very clearly state this in the beginning of this part!
>
> As Clause 4 makes no reference to XSLT 2.0 I see no reason for mentioning
> XDM there.

  I am not proposing to refer to XDM in the beginning of DSRL. I am
  agruing that Section 1 (Scope) clearly states that DSRL is fully
  implementable only when level 2 or 3 DOM is returned by the underlying XML processor,
  replacement text for all unparse entities are available, and references
  to parsed entities are not expanded. (If you insist on unparsed
  entities, we will need more.)

> >Yes, this is highly confusing to me. Since Annex B relies on XSLT2, I
> immediately started to look for the definition of entities in XDM.
>
> >I do not believe that XML parsers are obliged to provide replacement
> texts for all parsed entities.
>
> True

  Then, please clearly state that XSRL cannot be fully implemented on top
  of conformat XML processors when they do not provide replacement text
  for all parsed entities or they do not preserve entity references.

> >>>It should be made
> >>> clear that internal parsed entities are also outside the scope of DSRL.
>
> >> Why? If the DOM records them why cannot they be referred to and
> processed?
>
> >You restrict the scope of this part to those XML parsers which handle DOM
> Level 3
> streams. DSRL as defined in this part per se cannot be implemented on those
> XML
> parsers which handle the other data models such as XDM or the XML
> Information Set. This limitation should be very clearly stated in the
> beginning of this part.
>
> I have changed the wording to make this, I trust, clearer

  Which change? I would argue that this restriction be mentioned in
  Section 1.

> >However, even when we impose this very severe limitation, the DOM does
> not always record entity references. Dom Level 3 Core clearly say
>
> >"Moreover, the XML processor may completely expand references to
> entities while building the Document, instead of providing
> EntityReference nodes"
>
> >Thus, DSRL is implementable on only thowse XML parsers which
> handle DOM Level 3 streams, preserve entity references, and provide
> replacement text for entities. Which XML parser satisfies these
> requirements??
>
> Why do you insist on it being an XML parser that processes DSRL? I see no
> reason to impose any such restriction. Any XML processor that understands
> the XML naming rules, and can identify entity references and their
> replacement text, should be permitted to carry out DSRL processing.

  My question boils donw to this: is DSRL implementable on something
  different from Saxon 2, which does not really follow the semantics
  of XDM?

> >First, it should be clearly stated that "Entity" in your text mentions
> an interface "Entity" as defined in Dom Level 2 and 3. Without this
> clearification, this text is meaningless.
>
> I have added a definition of entity node to section 3 to clarify this
> imported term, even though it is in a note rather than normative text.
>
> >I would still argue that all XML parsers expand references to internal
> parse entities and that no DOM level 3 streams preserve such references.
>
> In that case how did I manage to process entity nodes using Saxon?

  Since it is non-conformant in handling entity references. One could
  argue that this non-conformant behaviour is useful, but ISO/IEC
  standards should not rely on non-conformant behaviours.

> >In my opinion, the first sentence in the above quotation justifies my
> interpretation.
>
> I beg to differ, most strongly. The phrase "XML does not mandate that a
> non-validating XML processor read and process entity declarations made in
> the external subset or declared in external parameter entities" specifically
> states that a non-validating XML processor (note the terminology, not an XML
> parser) need not process entity declarations.

  The phrase clearly say "external". I am talking about entities defined
  in internal subsets. I believe that XML processors are oblidged to
  expand references to such entities.

  4.4.2 of W3C XML 1.0 (fourth edition) says:

  [Definition: An entity is included when its replacement text is retrieved
  and processed, in place of the reference itself, as though it
  were part of the document at the location the reference was
  recognized.] The replacement text may contain both character
  data and (except for parameter entities) markup, which MUST be
  recognized in the usual way. (The string "AT&T;" expands to
  "AT&T;" and the remaining ampersand is not recognized as an
  entity-reference delimiter.) A character reference is included
  when the indicated character is processed in place of the reference
  itself.

> > I would like to make entity renaming
> and entity definitions of DSRL optional.
>
> OK, done

  Where did you incorporate the change? I would propose to introduce
  Section 8 "Conformance" and clearly state whether a conformant DSRL
  engine is required to support which feature.

> >You can say that the processing model works only when the underlying XML
> processors preserve entity references and provide replacement text for
> all parsed entities.
>
> Done

  It not clear to me what you changed. If I were you, I would introduce
  a new section named "Reference model" and separate it from Section 4.

> >As long as this complex situation is very clearly explained, I will not
> ague agains the use of XSLT2 in this non-normative appendix.
>
> Is the attached revision, which incorporates the changes note above, likely
> to get approval from the Japanese National Body?

  Unclear. We have to review it more carefully.

  By the way, XSLT2 is already a recommendation, but you referenced to a
  candidate recommendation.

  Regards,

  --
  MURATA Makoto <murata@hokkaido.email.ne.jp>

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

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