Should CDATA section markers be retained?
Origin: FYergeau@alis.com:
origin
Followups:
richard@cogsci.ed.ac.uk:
followup muraw3c@attglobal.net:
followup mhkay@iclway.co.uk:
followup
Core group discussions (MEMBER ONLY):
reference
Response:
CDATA section markers will removed from the Infoset.
After considering the views submitted on this issue, we have concluded
that the likely usefulness of CDATA section markers in the Infoset is
outweighed by the problem of maintaining them when translating between
character sets and the danger of implying that they are more than a
syntactic convenience. Implementations are of course free to record
whether text came from a CDATA marked section and use this information
when serializing.
Should we move the RDF schema to a separate Note?
Origin:
Core group discussions (MEMBER ONLY):
reference
Response:
We will remove the RDF schema from the Infoset spec and publish it
as a W3C Note.
See also:
issue query-17
Various editorial suggestions from Susan Lesch, W3C
Origin: lesch@w3.org:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The editor has incorporated most of these suggestions.
What should [element content whitespace] be for non-whitespace
characters in the absence of an element declaration?
Origin: richard@cogsci.ed.ac.uk:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
It should always be false for characters that are not whitespace.
The spec has been revised to state this.
Should [charset] be renamed?
Origin: richard@cogsci.ed.ac.uk:
origin
Followups:
marting@develop.com:
followup
Core group discussions (MEMBER ONLY):
reference
Response:
This property has been renamed [character encoding scheme] in accordance
with the WWW Character Model draft.
References:
reference
Are comment info items required (XML 1.0 does not require them
to be reported)? The spec should be more explicit about not being
a lower bound.
Origin: ok@cs.otago.ac.nz:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The Infoset does not require anything of processors. It is up to
a specification using the Infoset to specify whether it requires
any item or property. We have added a sentence to the introduction
stating that the Infoset is not a minimum requirement for XML
processors. The conformance section states the requirements on
specifications using the Infoset.
Should we provide pointers to the notations/entities referred
to by attributes of those types? Also idref?
Origin: richard@cogsci.ed.ac.uk:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
We have decided not to add this. It might be added to a future version
if it turns out to be useful to multiple specifications.
Bugs in the RDF
Origin: connolly@w3.org:
origin
Followups:
connolly@w3.org:
followup
Core group discussions (MEMBER ONLY):
reference
Response:
Dan's corrections will be incorporated (when the RDF schema is
published as a Note).
Restore attribute [children] property so that entity boundaries
are described. Base it on DOM level 2.
Origin: plh@w3.org:
origin
Followups:
richard@cogsci.ed.ac.uk:
followup plh@w3.org:
followup richard@cogsci.ed.ac.uk:
followup plh@w3.org:
followup plh@w3.org:
followup richard@cogsci.ed.ac.uk:
followup
Core group discussions (MEMBER ONLY):
reference
Response:
We looked at DOM level 2 and still do not believe this can be done in
a way that is both consistent and useful. Entity boundaries only make
sense before normalization, and the XML 1.0 specification requires that
attribute values be normalized. Furthermore, the unnormalized value
cannot be normalized without knowledge of which characters were
represented by character references. In any case, we have now decided
to remove entity markers from text content too.
See also:
issue query-10
What if an unexpanded entity turns out to be not well formed?
Origin: plh@w3.org:
origin
Followups:
richard@cogsci.ed.ac.uk:
followup plh@w3.org:
followup richard@cogsci.ed.ac.uk:
followup plh@w3.org:
followup plh@w3.org:
followup richard@cogsci.ed.ac.uk:
followup
Core group discussions (MEMBER ONLY):
reference
Response:
We consider this out-of-scope for the Infoset. It is a problem to be
addressed by specifications which allow insertion of entity references.
Don't provide prefix on elements/attributes.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The [prefix] property is required so that XML 1.0 reporting requirements
can be expressed in terms of the infoset.
Prefix should be absent (=null) rather than empty (string).
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
We note that the DOM uses null for this purpose. We will change to match
(actually we will use "no value").
See also:
issue query-5
Why does attribute refer to element prefix?
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
It's a cut-and-paste mistake, now corrected.
[in-scope namespaces] should only contain "newly-defined"
namespaces.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
This would make it harder to cut-and-paste elements between documents
(as in XInclude for example) keeping their namespaces intact. Furthermore,
our model matches XPath's. Note that since there is no parent
property, no distinctness of items is implied.
Clarify whether xmlns="" (ie default namespace undeclaration)
counts as a namespace attribute.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Yes, it does. Clarified.
Get rid of the entity items for predefined entities.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The built-in entities are not magic; they are just internal entities that
you don't have to declare. So they should be treated like other internal
entities. However, we elsewhere decided to remove entity boundaries
so they will disappear anyway.
See also:
issue query-10
Replace null with absent.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Accepted. We will use "no value" and "unknown" as appropriate.
Get rid of CDATA section markers.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response: see
issue core-1
Attribute value should be given and marked as normalized or not.
What about entity boundaries in attributes?
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response: see
issue dom-1
"Aren't entities resolved to strings?"
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
If this refers to the ENTITY and ENTITIES types for attributes, these
are unparsed attributes, which are not subject to replacement.
Default attribute type should be CDATA.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Having null (now "no value") as default type gives
more information than CDATA and (more importantly)
is consistent with other cases of
absent definitions. Applications should indeed treat it as semantically
the same as CDATA.
Can unexpanded entities appear in attributes
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
No. Only internal entities are allowed in attributes, and internal
entities must be expanded according to XML 1.0.
Don't preserve entity boundaries.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response:
We accept this change, in part because we agree that they are not part of
the logical structure of a document, but more importantly because we
do not expect specifications other than the DOM to use them. As a
consequence, we are also removing external and internal entity items,
and modifying the document and unexpanded entity reference items
accordingly.
Why are attributes and elements treated differently wrt
character info items?
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Attributes are represented as strings because they are normalized, and
because there are no properties applicable to the individual characters.
Is document info item required if there is a DTD?
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Yes, in so far as anything is required - if a document has a DTD then there
is a DTD item in its infoset. This is stated explicitly in section 2.8.
Standalone should be boolean.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
We prefer to use the same term that is used in the XML document itself.
Why [base URI] on elements?
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The base URI of an element is used for the interpretation of relative URIs in
its attributes and content.
It would be possible to construct the base URI from that of the containing
entity and from any xml:base attributes on the element or its ancestors,
but this is such a common concept that it seems useful to define it
in the infoset. In any case, now that we are removing entity boundaries
it is essential.
Why are there two properties for types in the PSV Infoset?
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The Schema group has decided to only augment a document's infoset, not
change it, so it has to use a new property.
Rename owner to parent.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
We want [parent] to be the inverse of [children], and [attributes] must be
separate from [children]. This was a
requirement in the XPointer-Infoset liaison statement.
References:
reference
An XML schema as well as an RDF one would be useful.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
We agree. Richard Tobin expects to submit one for consideration as
a W3C Note.
See also:
issue core-2
More examples and use cases would be useful.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
We will add some if time permits.
A couple of editorial changes.
Origin: mrys@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Editor will incorporate these or similar changes.
Several interesting observations, no editorial or substantive issues.
Origin: reagle@w3.org:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
No action required.
Description of prefix is wrong for no-prefix case.
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
Fixed (it now refers to unprefixed names rather than elements not
belonging to a namespace).
Clarify description in case of "xmlns".
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
This has been clarified.
[namespace attributes] property is odd; go back to [declared namespaces] containing Namespace info items.
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
They are represented as attributes to correspond more directly to the
XML 1.0 reporting requirements. The namespace for namespace declaration
attribute was not invented for the Infoset but already existed in DOM
Level 2.
Get rid of prefix for attributes.
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response: see
issue query-1a
Error in description of [prefix] for attributes (has element
instead of attribute).
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response: see
issue query-1c
Add children property for attributes.
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response: see
issue dom-1
Why [base URI] on PIs (can get it from containing element)?
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
The base URI of a PI at the top level of an entity is not necessarily
the same as that of the containing element.
Why [element content whitespace]?
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
This is needed to allow the reporting requirements of validating XML
parsers to be described in terms of the Infoset.
Get rid of CDATA section markers.
Origin: marting@develop.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response: see
issue core-1
Microsoft concurs with the comments of the Query WG.
Origin: jmarsh@microsoft.com:
origin
Core group discussions (MEMBER ONLY):
reference
Response:
See reponses to individual Query WG comments.
Document item should have [charset] property.
Origin: amyzing@talsever.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response:
The [charset] property of the [document entity] property of the document
information item provided this information. However, now that we have
removed external entity items, this property has been moved to the
document information item.
Are defaulted attributes in the infoset? (Prolog to 2.3
says no.)
Origin: amyzing@talsever.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response:
This seems to be a misreading. It actually referred to "attributes declared in
the DTD with a default value of #IMPLIED", ie attributes without a default.
The wording has been changed to make this clearer.
Entity markers should be in attributes if they are in text
Origin: amyzing@talsever.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response: see
issue dom-1
Why are entities and notations in the document item rather than
the DTD item.
Origin: amyzing@talsever.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response:
Because the mapping of entity and notation names to system and public
identifiers is a property of the document as a whole. Furthermore,
not all entities are declared in the DTD (the document entity, maybe
built-in entities).
Comment and PI children of DTD are useless out of context
Origin: amyzing@talsever.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response:
We agree that comments in the DTD are of little use out of context, and we
will remove them. PIs are needed however; stylesheet PIs may appear in
the DTD.
Support calls for clarification of namespace items
Origin: amyzing@talsever.com:
origin
Core group discussions (MEMBER ONLY):
reference reference
Response:
See responses to the individual comments.