FW: MSFT's Infoset WD response

As requested by David.

Best regards
Michael
--
Michael Rys
Microsoft XML Repository -- We store the Web and more
mrys@microsoft.com, rys@acm.org


> -----Original Message-----
> From:	Michael Rys 
> Sent:	Friday, May 21, 1999 6:32 PM
> To:	w3c-xml-infoset-wg@w3.org
> Subject:	MSFT's Infoset WD response
> 
> Dear WG members. Here are Microsoft's comments on the working  draft.
> 
> I will organize them into the following categories:
> 
> A. Namespace issues
> B. Schema issues
> C. Reference issues
> D. Miscellaneous
> 
> Best regards
> Michael
> 
> A. Namespace Issues
> -------------------
> 
> 1. Namespace information item
> 
> Having a namespace information item that is visible during the
> scope of its existance would be a better approach than just  
> encoding the information in the attribute information item.
> 
> This would for example allow a domain-specific XML processor
> (such as XSL) to always have the correct namespace information
> available for elements, attributes and even namespaces used in
> content.
> 
> For example in
> 
>  <xsl:template xmlns:xsl="xslns" xmlns:foo="myns">
>      <xsl:for-each select="//foo:bar"> ...
> 
> two namespace information items would provide (prefix, URI)
> and the elements and attributes would reference both the 
> currently active namespaces and the namespaces used for the 
> element/attribute. Even if we would not provide the currently
> active namespaces, a processor could get that information by
> traversing up the tree, IF we preserve the namespace attributes
> that define the namespace. An XSL processor needs this information  
> in order to correctly interpret the //foo:bar query.
> Other XML grammars that want to reuse namespaces in content will  
> have this same requirement.
> 
> This leads me to the next point:
> 
> 2. Namespace-aware vs Namespace-unaware processing
> 
> In principle, we think that a namespace-aware processor should
> produce all information that a namespace-unaware processor 
> surfaces plus the additional information about the namespaces.
> 
> Code written to work in a non-namespace aware parser/OM (the  
> majority of the cases today) should not break in a namespace-aware  
> parser/OM.
> 
> Thus:
> a. The element and attribute names should provide both a
>    qualified name that is available in both "modi". In addition,
>    the namespace-aware processor should provide a reference to
>    the namespace information item and the local part of the name.
> 
>    We believe, and apparently the DOM committee does as well, that 
>    the prefix should be available in an upward compatible name.  
> 
> b. All attributes used to define namespaces etc. should still be
>    exposed by a namespace-aware processor. The current design    
>    implies that the namespace declaration attributes vanish when 
>    in namespace mode.  This is pointless, potentially 
>    destabilizing, and has the effect of making it impossible to 
>    figure out what the scope of the namespace definition is.
>    For example, hiding the attributes will significantly confuse 
>    DOM writers who use the Level 1 interfaces that don't provide 
>    namespace support - the attributes will be available in the API.
> 
> B. Schema issues
> ----------------
>  
> The design allows one to get from an attribute to the DTD item  
> defining the attribute.  There is 
> - no corresponding facility for elements (i.e., there is no 
>   element declaration item), and 
> - no facility to get from an attribute to its definition if the 
>   definition is in some form other than DTD.  
> 
> It is highly likely that the future will bring schema formats other  
> than DTD, and since these schemas will use XML instance syntax, 
> they will be extensible, meaning that they will contain an  
> unpredictable range of attributes and elements not forseeable in  
> any closed information model.  We need a way to navigate from an 
> attribute or element to its definitional information item, without 
> prejudice on the type of that item (be it based on XML Schema or
> DTD).
>  
> Note that we understand that the mandate of the WG is to
> describe XML 1.0 plus namespaces and not any upcoming and not yet  
> defined schema definition. However, we strongly feel that
> we should provide for future extension in that area and not lock 
> ourselves in.
>  
> C. Reference issues
> -------------------
> 
> We strongly believe that having a reference information item that
> provides linking information (either via ID/IDREFs, URIs, 
> XLink/XPointer or any other mechanism) should be part of the
> infoset.
> 
> D. Miscellaneous
> ----------------
> 
> Numbers at the start of the following paragraphs indicate sections
> in the working draft.
> 
> 2.1.1 item 1 and 2.1.2 item 4 refers to a "document element."  The  
> XML 1.0 spec defines this a "root" (providing "document element"  
> only as an appositive).  
>  
> 2.3: On the question of xml:lang and xml:space, I believe it would  
> be very good if the information model provided a context to  
> determine the language and whitespace settings on any information  
> element - you shouldn't be required to walk the tree to determine 
> the current language or whitespace setting in scope. 
> 
> 2.6: In the second paragraph there is specific language regarding  
> CR and LF. Surely, CR and LF (or a collapsed representation with  
> LF) should be representable when xml:space="preserve", right? Is  
> this the intent?
> 
> 2.6.2 (Character Optional Properties).  I know that the RDF group  
> looked at this, and decided that xml:lang needs to be a property of  
> the contained string, at least in their model.  I believe  
> Murata-san led this.  I do not, however, know that it affects the  
> Infoset, since one cannot change xml:lang mid-string.
> 
> 2.9.1: there is language in bullet 1 that indicates that parameter  
> entities are modeled. This is confusing in light of that <!ELEMENT  
> ...> is not modeled. Modeling parameter entities (which most schema  
> proposals are trying very hard to avoid) hardly seems appropriate  
> without a complete modeling of the DTD. 
> 
> While entity information items are optional, it seems that 
> requiring support for all kinds of entities (such as - yuck -
> external parameter entities) if entity information items are 
> provided is too strong. We would rather see the scope of the 
> provided information to be optional as well (e.g., provide only
> internal general entities but not external parameter entities).
> 
> Another question w.r.t. entity info items is, whether an unparsed
> external entity needs to be represented or if this could also be
> made optional. For example, an XML database processor may not
> want to deal with such unparsed data in a special way and just
> treat it as character data.
> 
> 2.11.1: Include the namespace information item.
> 
> 3. If a namespace-aware processor just adds information, then
> this section needs to be changed.
>

Received on Thursday, 27 May 1999 02:16:57 UTC