W3C home > Mailing lists > Public > public-qt-comments@w3.org > October 2010

[Bug 10982] [DM11] RFE: Retrieving the typed-value that a Text Node represents

From: <bugzilla@jessica.w3.org>
Date: Wed, 06 Oct 2010 16:39:04 +0000
To: public-qt-comments@w3.org
Message-Id: <E1P3X1E-00018o-4X@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10982

--- Comment #4 from Rick Yorgason <rick@firefang.com> 2010-10-06 16:39:03 UTC ---
The document model doesn't care if your document is schema-validated,
*especially* if you're using direct construction :)

(And we *are* talking about direct construction now, right?  Otherwise, I'm not
sure how a mutable operation like moving a node could occur.)

In the example you provided, your new document might be invalid according to
the schema, but it would be perfectly valid according to the document model.

Also, you could just as easily construct a document that doesn't validate
against your schema by moving around ordinary, untyped text nodes.

Anyway, it sounds less like you disagree with my RFE and more like you disagree
with clause 3.3.1.3.

I can certainly understand why this feature would be an inconvenience for some
implementations; for instance, if you store the schema-validated type in the
element and use that to cast the text node to the appropriate typed-value on
request.  NOT having this feature is equally as inconvenient for implementers
who store the typed-value and generate the string-value on request (which is a
perfectly reasonable thing to do, and even the standard says so).

That's why I think this feature should be optional.  If the implementation
doesn't have the data available, falling back on untypedAtomic is a perfectly
reasonable thing to do.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 6 October 2010 16:39:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:44 UTC