See also: IRC log
<Steven> Scribe: Steven
<John_Boyer> Editor's draft, diff marked version: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html
<John_Boyer> Agenda: http://lists.w3.org/Archives/Public/public-forms/2007Sep/0041.html
John: We have 48 issues to review, about 16 a day
Charlie: Plus the SMIL3
review
... which has to be in on Friday
John: Some issues are all on the
same subject so we can do them at the same time
... We have an issue about the XForms 1.1 schema too
... the current schema is not up to date
... so we need to review it and update it
... and I'm going to pick on MarkB here
... since he has an overdue action item on this
... we should do this on Friday
... On the XML conference, we have a 2hr 15 min session so our
schedule is OK
... so we need to gather the stuff and make a blurb
... bios, pics and abstracts
... to advertise the event
<scribe> ACTION: Leigh and Steven to create conference blurb [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action01]
<trackbot-ng> Created ACTION-396 - And Steven to create conference blurb [on Leigh Klotz, Jr. - due 2007-09-19].
trackbot-ng, help
<trackbot-ng> See http://www.w3.org/2005/06/tracker/ for help (use the IRC bot link)
trackbot-ng, pointer?
John: Where do we record future meetings?
Steven: Wiki http://www.w3.org/MarkUp/Forms/wiki/FaceToFace
... we have meetings planned up to October next year
John: The charter says 3 or 4 meetings per year, so we could drop one
Charlie: Let's discuss all this Friday
<Nick> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-focus
John: That's the spec-ready
text
... part of the problem has been a lack of rigour over what a
form control actually is
... The diffs you see are against the last call version
... So I have defined 'core' controld and 'container'
controls
<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-setfocus
Nick: I have no problem with these changes, but I do with the definition of repeat object
John: We can do that later
Charlie: But isn't there a need to set focus on a group?
Steven: What would that mean?
What can I do to a group?
... I like this approach here because it means I can focus on
the first control in a group without worrying about
relevance
Rafael: This is what we do, when we set focus to the group
Charlie: I'm not pushing strongly, but point out that there are other use cases
Nick: If you want to do that, you can cancel the event, and everyone is happy
Charlie: OK. As long as there is a work around
RESOLUTION: Accept issue 155
<John_Boyer> http://htmlwg.mn.aptest.com/xforms-issues/
John: My issue, a bit weird
... the spec doesn't say if the index changes, we do a
rebuild
... but it needs to
... because of the index() fuction
... the problem is that the index function doesn't create
dependencies
... so there is something wrong with the index function
Rafael: for the dynamic UI in
general
... it would be useful to use the index function
... complicated to do in XForms right now
John: The spec says about dynamic
predicates must work in UI bindings
... without saying how
... but it does at least require it
... Are people happy with this?
Steven: I like declarative defintions, where it says it should work, without saying how to implement it
[discussion of implementation techniques]
John: My proposal is to leave it as is for 1.1, and address in the future
Charlie: We need to consider it in the context of splitting model and UI
Steven: We discussed in the past, and we need to rething the idea of having a sort of hidden instance that reflects the values in the UI, like repeat indexes, and then everything drops out, since you have the necessary constrains, and you can even bind to them
RESOLUTION: Defer issue 24 to XForms 2.0
Issue 153
John: THis is about the difference between the markup and the shadow tree
Nick: You need to treat it as if the repeat element is in the DOM
Charlie: I agree
John: That's the model I
prefer
... but I left the text to allow either approach
<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-processing
Steven: It says that there is an
implicitly generated group element
... what if the CSS selects on groups?
John: The problem with the idea
that repeated items add items to the DOM is that they may
generate DOM mutation events
... the problem comes with DOM Events
... and the moment that action handlers are registered with
respect to model creation and UI creation
... <repeat id="x"><action ....
... gets expanded to
... <repeat id="x"><action.../><group>
Nick: No, to <repeat id="x"><group><action ev:observer="x"/>
John: Good
... so we need to say that
Nick: Why?
John: Because events can happen before the UI gets created
Nick: But other 'magic' things happen anyway; leave it to the implementor
John: I think we all agree that
the sentence "The capture and bubble phase of XML Events
dispatched to these run-time objects is confined to the repeat
object." should be removed in
... 9.3.3
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-processing
Steven: As a point of process, we should always create dated versions when we discuss them so that the links in the minutes will work in the future
[John edits]
<John_Boyer> 28<21note20 diff28="add28">rn 28<21p28>The capture and bubble phases of XML events dispatched to the run-time objects behave as if the rn repeat object were a child of element 28<21el28>repeat28</21el28>. The repeat template content, including rn action handlers are made unavailable to the host language processor.28</21p28>rn 28</21note28>
<br/>
Restart
<John_Boyer> 28The capture and bubble phases of XML events dispatched to the run-time objects behave as if the repeat object were a child of element repeat. The repeat template content, including action handlers, are made unavailable to the host language processor. Hence, action handlers declared within a repeat respond only to events dispatched to elements withi
<John_Boyer> 28the repeat object, not to the repeat element itself.
[Last sentence gets deleted]
[XML gets deleted]
<John_Boyer> 28The editor's spec available at the start of the FtF is now at http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff-20070911.html
<John_Boyer> 28http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Misc?id=124;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1
Issue 124
RESOLUTION: Don't change the abstract
Issue 125
John: We disagree, because we don't want to be tied to their timeframe, and we don't want to be tied to their processing model
RESOLUTION: Reject issue 125
Issue 126
Charlie: Let's put it in, but not reference it
RESOLUTION: Modify and accept issue 126: ADD odf, BUT DON'T REFERENCE IT
Steven: I have done a talk,
see:
... http://www.w3.org/2007/Talks/05-15-steven-xforms11/
... and search for XForms 1.1
http://www.w3.org/MarkUp/Forms/2007/xforms11-differences.html
RESOLUTION: Accept issue 162
Steven produced initial text at URL above
this only reflects the last call version
<John_Boyer> 28<http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Misc?id=171;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1>
<scribe> ACTION: Nick to convert differences with XForms 1.0 to xml spec [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action02]
<trackbot-ng> Created ACTION-397 - Convert differences with XForms 1.0 to xml spec [on Nick Van Den Bleeken - due 2007-09-19].
RESOLUTION: Reject issue 171
John: It's just so easy to create your own root element
RESOLUTION: Accept issue 163
John: We need examples for:
replace all, replace instance, replace none
... xforms-submit-done, xforms-submit-error
... dynamic URL in the resource section
... header use
... maybe not that last one
... since it would be too involved
Mark: I agree
John: So this means some spec change
Nick: So this will be a substantial change
Steven: but not significantly substantial :-)
RESOLUTION: Accept issue 4
<scribe> ACTION: Steven create submission examples [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action03]
<trackbot-ng> Created ACTION-398 - Create submission examples [on Steven Pemberton - due 2007-09-19].
<scribe> ACTION: John create repairs for order of children of submit [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action04]
<trackbot-ng> Sorry, amibiguous username (more than one match) - John
<trackbot-ng> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)
<scribe> ACTION: johnboyer create repairs for order of children of submit [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action05]
<trackbot-ng> Sorry, couldn't find user - johnboyer
trackbot-ng list
trackbot-ng, list
trackbot-ng, help
<trackbot-ng> See http://www.w3.org/2005/06/tracker/ for help (use the IRC bot link)
trackbot, status
trackbot-ng, status
<scribe> ACTION: John_Boyer to do nothing [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action06]
<trackbot-ng> Sorry, couldn't find user - John_Boyer
Tracker's url: http://www.w3.org/2005/06/tracker/xforms/
<scribe> ACTION: JohnB to do nothing [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action07]
<trackbot-ng> Sorry, couldn't find user - JohnB
<scribe> ACTION: JohnBoyer to do nothing [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action08]
<trackbot-ng> Sorry, couldn't find user - JohnBoyer
LUNCHTIME
EMITHCNUL
<klotz> Dark outside.
klotz? Are you on?
<klotz> yes, skyped you a few times but you refused.
I wasn't here!
Wait leigh!
I have to add you to conference
You can't call me
Issue 137
<scribe> Scribe: Charlie
<klotz> i hear Steven but nobody else; is that expected?
xforms uses schema 1.0 but dayTimeDuration and yearMonthDuration are in 1.1
c/in 1.1/not in 1.0
<klotz> i will stick with this for now then thanks
john: we're interested in the xforms: types since those allow empty content
and can be used without schema qualification
steven: we've adoped these types but in our namespaces
john: the suggestion was to use them in the original xsd namespace
but ours were introduced to allow for the empty content
steven: reply should be we introduced the xforms namespaced types to allow for the empty content, the xsd namespace can be used
if the original types are desired
no use case to pull them into the default namespace
markB: don't see the empty types as an advantage
have to maintain two set of type defs
<klotz> i had proposed MIP optional to mean elide-if-empty before submission validation.
john: seems easy to add these two types to the implicit schema that provides the rest of the xsd types
markB: no big problem to include them if we want
<Nick> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#datatypes-schema
nick: where do we list those implicit types?
since they're not in schema 1
John: needs to be additional text in section 5.1 to mention them separately
nick: if we add these two but if xsd:duration is not allowed as stated in 5.1 how can these new ones work?
john: we exclude the ones
mentioned since we define an xforms namespace that lists all
types except for these four..don't know why they were
excluded
... likely to direct users to our types
<klotz> they were new types added after xforms 1.0 by the xml schema folks
john: we could stick with xml
schema 1.0 types, and hence not add them now
... xsd:duration was excluded since it didn't allow empty
content
<klotz> xsd:duration was excluded because it's not comparable; it should have been an abstract type.
<klotz> which is longer 1 month or 30 days?
john: proposed resolution that we stick with just schema 1.0 types and extend them when we transition to schema 2.0
<klotz> it's not clear that it is a schema 2.0 type.
john: and xforms ones can be used with the required MIP to allow/enforce emptyness
c/to schema 2.0/to later version of schema
<klotz> i think they types are defined now in XQuery and are imported by W3C magic already.
<John_Boyer> The fuzzy answer is that one month is longer
<John_Boyer> Since it is longer 7 out of 12 times
<Nick> XForms 1.1 is based on XML schema 1.0, we only want to add schema 1.0 data types to XForms 1.1. We will add new schema types when we move to a newer version of the schema spec.
<klotz> The comparable issue is why we removed xsd:duration; I can find the minutes, but it was Micah.
proposed resolution: for issue 137 stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
markB: looks ok
Leigh: not clear this comes from schema itself
john: not available from xml schema 1.0 recommendation
<John_Boyer> We are the ones who write the implicit schema that declares which datatypes from XML Schema we support
<klotz> ok
john: we could state more
precisely that we support xml schema types defined in schema
rec and cite that doc
... though our link in the reference section doesn't qualify
the spec version with a date
... but the 2004 version of schema 1.0 doesn't include these
types either
<Nick> http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes
nick: appendix addresses adding durations to the existing types, so this might allow a mechanism using schema 1.0
john: this is how to compute a dateTime
Steven: proposed resolution: for issue 137 stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
RESOLUTION: for issue 137 stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
<scribe> ACTION: John Boyer to reply for issue 137 as in resolution [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action09]
<trackbot-ng> Sorry, amibiguous username (more than one match) - John
<trackbot-ng> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)
cites the xquery data model for the same two types, should be the same resolution
<scribe> ACTION: john boyer to respond to issue 7 similarly to issue 137 [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action10]
<trackbot-ng> Sorry, amibiguous username (more than one match) - john
<trackbot-ng> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)
John: issue is asking for clarification of lexical vs value space
steven: i think they're right, we should do this
we're talking about values in the model but not in the controls
we should clarify the difference here, we're not requiring users to enter xsd types in that format
john: we should add something to the text to make this clear
but in some cases we're not clear as to what actually go into the model, e.g. email
c/go/goes
john: section 8.1.1 states the
display representation is not required to match the "lexical"
value -- meaning here the value-space value
... so our own terminology is not consistent, but we do make
the distinction
steven: would like credit cards to be explicitly added to this list
<klotz> i had that in xforms 1.0 example but it was removed
<klotz> i had it in the value space though so that was why
nick: this may be more clear
john: we could leave "display representation" in parens
but we should clean up the text
and in section 5 we don't have to define lexical vs. value space -- that's xml schema
steven: reply has been sent that we agree
<scribe> ACTION: john boyer to fix section 8 text, and also include in section 5, adding note referring to section 8 [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action11]
<trackbot-ng> Sorry, amibiguous username (more than one match) - john
<trackbot-ng> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)
<Steven> ACTION: jboyer to do nothing [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action12]
<trackbot-ng> Created ACTION-399 - Do nothing [on John Boyer - due 2007-09-19].
<raman> buenos dias!
hola
Steven: i have an action item for this already
<raman> on the bus going to work ... thought you guys were in the middle of your siesta when I first joined (incorrectly) the #xforms channel
i'll check out the previous discussion
john: don't see an action for issue 102
<scribe> ACTION: steven to respond to issue 102 [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action13]
<trackbot-ng> Created ACTION-400 - Respond to issue 102 [on Steven Pemberton - due 2007-09-19].
<Steven> http://lists.w3.org/Archives/Public/public-forms/2007Aug/att-0086/20070829.html#topic10
john: text in section 6 on MIP
should also be reflected in 8.1 common to all controls
... we already have some similar text there on valid and
invalid states
... stated as MUST for valid/invalid, not should
John: i've moved the DOM interface subsection into section 4 on the processing model, didn't really want a top-level section for it
RESOLUTION: move DOM interface hasFeature method discussion to section 4
<John_Boyer> 28<http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=156;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1>
John: aaron asks whether
hasFeature should return 1.1
... when referring to DOM interface
... the feature string is referring to the
DOMImplementation
... not referring to the entire spec
... org.w3c.xforms.dom 1.0 is the version of the interface
we're supporting
... we haven't changed this interface in xforms 1.1
... we're not talking about the version of xforms here, but of
DOM
... the property function will return the level of xforms which
seems to be what aaron wants
RESOLUTION: return value for hasFeature for DOM interface is that it returns 1.0 level of the DOM not referring to xforms 1.1
John: suggestion is to use xpath 2.0 now
Steven: too big of a change
John: we resolved to do this
after xforms 1.1
... there are some open issues which need to be resolved, e.g.
semantics of "if"
... i've inserted text into the issue DB assuming we'll do this
in xforms 2.0
... assuming xforms 1.2 is mostly about ease of authoring, not
foundational issues
... and we did deprecate "if" laying the foundation for xpath
2.0
... and removed the rationalization of the return type of
choose()
... and other issues will require actual transition to xpath
2.0 which will be a major revision to xforms language
RESOLUTION: for issue 140 to defer adoption of xpath 2.0 to later version of xforms
john: this should go into "defer" state -- we agree it's coming
xpath 2.0 provides more formal definition of evaluation context which would help
Nick: should we mention a specific xforms version when we'll adopt xpath 2.0?
john: probably good to start
laying expectations for when we'll some of these things
... so we should in response to issue 140 say xforms 2.0
explicitly, yes
RESOLUTION: for Issue 141 that xpath 2.0 will be adopted in a future xforms version
John: issue is that some
functions in xforms are similar to those in xpath 2.0
... e.g. boolean vs boolean-from-string() in xpath 2.0
... suggestion is that they be xforms namespace qualified
... and give users some way to select the function namespace to
be used
... but xpath 1.0 processors don't allow for selecting a
function namespace
RESOLUTION: for issue 143 defer namespacing for xforms functions to discussion of xpath 2.0 in later version of xforms
<klotz> i will wander off to eat breakfast and back in a bit.
<Steven> ack
john: "if" function not allowed
in xpath 2.0
... so thinking about transition strategy to xpath 2.0 is
important
... no solution suggested
steven: response could be we have deprecated it and are thinking about transition strategy
nick: we could in xforms 2.0 prefix "if" with namespace
john: we might not even keep it
in xforms 2.0
... given that xforms 2.0 will be associated in developers'
minds with xpath 2.0
RESOLUTION: for issue 144 not to namespace qualify "if" in xforms 1.1
john: issue is the id function in
xforms given its semantics are similar but not identical to id
in xpath 2.0
... we designed id in xforms to match xpath 2.0 as closely as
possible, to prepare for transitions
RESOLUTION: for issue 149 design of id function unchanged -- any differences with xpath 2.0 to be addressed when we transition to it
<John_Boyer> 28<http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=145;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1>
John: issue is around non-pure functions like random(), but now() and others have this problem already
nick: issue is around reordering
of function calls to optimize xpath engine
... but as you say this is already true in now() in xforms
1.0
john: do xpath engines do this
type of optimization?
... if the idea is to avoid re-running functions multiple times
if they have the same args this is ok, no?
nick: this occurs across
different xpath expressions, not just within a single one
... replace function call with returned constant value
john: xpath 1.0 recommendation
doesn't suggest this
... xslt may optimize calling xpath
steven: don't see how one could solve this...always call random with now() as param...no solution to the opposite
john: could replace the function with an action that puts the value into a node
nick: problem is that these are functions
john: our problem space consists
of functions that can be on mutated underlying documents and
hence change on repeated calls...e.g. id()
... but this is not the case that the function itself is
mutating the dom as side-effect
... we don't define functions that mutate the DOM while
running
RESOLUTION: for Issue 145 to accept semantic limitations of random()
<scribe> ACTION: jboyer to respond to issue 145 [recorded in http://www.w3.org/2007/09/12-forms-minutes.html#action14]
<trackbot-ng> Created ACTION-401 - Respond to issue 145 [on John Boyer - due 2007-09-19].
John: suggestion is for the decode function to return an additional error in the case that the result is not valid XML even though it is valid UTF-8
nick: issue relates to control characters
<klotz> xml1.1 allows all but char 0, when escaped as numeric entities. xml 1.0 is less forgiving.
john: char is the one with extra restrictions
* test
<Steven> http://www.w3.org/TR/REC-xml/#charsets
steven: ok to store these values in an instance, issue is related to serialization when they need to be encoded
leigh: which character codes?
steven: control chars
leigh: these can't be encoded as
xml chars
... in xml 1.0, can do this in xml 1.1 except for char 0
john: so this remains a problem
for the serializer
... still looks like normal element content allows these
control chars
<klotz> http://www.w3.org/TR/xml11/#charsets
<klotz> http://www.cafeconleche.org/books/effectivexml/chapters/03.html
john: so the question then is whether xpath data model allows for these characters
<klotz> ask michael kay
john: xpath string, a sequence of UCS characters
steven: so if you have characters in the xpath data model that can't be serialized, this isn't a problem with decode
leigh: good to separate issues
but as of today result of decode might not be representable in
xml
... should put in a note to this effect
<klotz> yup. and even in xml11 there's still char 0, so it won't work then.
steven: question is whether error handling goes in encode/decode or somewhere else
leigh: anyone using infoset will
run into this problem
... xforms without xml would be ok in the data model
john: but if this is limited to encode/decode we could in fact provide an error condition
leigh: suggesting a note saying that arbitrary binary data in the instance won't in general be supported
nick: other problem is you won't see if unless you serialize
leigh: lots of parsers throw errors too
nick: some serializers even process it, but output can't be read in again
john: one approach is to
post-process decode for illegal chars and generate an
error
... do encode after decode and check for valid content
nick: what if you want to skip over some known non-xml data and process the rest?
<klotz> xsd:string
<klotz> http://www.w3.org/TR/xmlschema-2/#string
john: we don't define what happens if serialization fails on submit
leigh: turns out to be a
validation error
... since xsd:string excludes non-xml chars
nick: but can have nodes with no type
john: but those would be string
by default
john: everything derives from
string
... so technically we're ok
... since validation would fail
<klotz> http://www.stylusstudio.com/xmldev/200203/post00880.html
<klotz> Above is Michael Kay on the topic of DOM support for control characters.
<klotz> But the data is invalid as soon as you enter it becasue it isn't an xsd:string
<klotz> OK, not that I can hear, but I can't live with this.
John: deciding to keep names encode, decode?
<John_Boyer> Can't live with what?
why?
<John_Boyer> but non-char data is allowed by XPath data model
<John_Boyer> string defined as set of UCS chars
leigh: will cause problems with any xml-based implementation
<John_Boyer> They won't necessarily want to store it
leigh: within an xpath expression, this is fine
steven: so you're ok with the function returning possibly non-xml valid chars?
leigh: yes
... question is when and where do impls tell people it's
invalid?
<John_Boyer> true that the non-XML data will not be valid according to xsd:string, but
<John_Boyer> we proposed ot add a comment to say that the non-validity will prevent submission before serialization
<NickVdB> DocumentBuilder db = dbf.newDocumentBuilder();
<NickVdB> Document doc = db.parse(new File("src/resources/xml/simple.xml"));
<NickVdB> doc.getDocumentElement().appendChild(doc.createTextNode("\u0001\u0002"));
john: so should decode look for
invalid content and raise error?
... and live with the limitation that we can't operate over
invalid data...
nick: but perhaps there are bugs
in some impls related to storing non-xml data
... and we should not limit ourselves accordingly...
john: what's the purpose of decode? to recover the results of things we encoded, anything else?
<NickVdB> http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html#ID-1312295772
john: we now have the ability to submit just text
nick: but text in DOM level 1 stipulates that text is valid xml
<klotz> The DOM refers to character data in XML.
<markbirbeck> ah...
<markbirbeck> was just asking that in the Skype window. :)
<markbirbeck> thanks
john: so we don't need a note in
submission since setvalue and calculate shouldn't allow
non-valid data
... just need a note in decode since it's the only window for
this
<klotz> calculate works ok with data that doesn't match the xsd tyep though, just not submission.
RESOLUTION: to issue 146 calculate and setvalue amended with exception if data contains invalid xml chars, and note added to decode to this effect
<klotz> Apache Xerces-C implements XMLChar1_0 and XMLChar1_1 separately: http://xerces.apache.org/xerces-c/apiDocs/classes.html
john: other part of 146 is generic name of encode
<klotz> DOM level 2 defines INVALID_CHARACTER_ERR http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/java-binding.html
<klotz> he does suggest two encode functions rather than one, base64 and hexbinary, so that suggests names.
john: proposed resolution --
prefer more generic name since it allows to control the
encoding from instance data and add more encodings later
... group already decided against two functions
<klotz> ok
* leigh beat me
<John_Boyer> can anyone not live with above proposed res
RESOLUTION: for issue 146 maintain the original names for encode/decode to allow for controlling encode/decode from instance data and to add more encodings later
<Steven> ok
<klotz> what is john saying?
[bye!]
<klotz> maybe we should redefine handling of xsd:base64 and xsd:hexbinary types to say that we automagically encode data when putting it there.
<John_Boyer> we're on to the question of whether serializations other than UTF-8 are needed
<John_Boyer> for the interim format for encode decode
<John_Boyer> for encode we UTF-8 serialize, then convert to b64 or hex
<klotz> if it's binary data it really should be bytes not characters.
<John_Boyer> XPath 1.0 seems to reference UCS only and implies that UCS-2 is acceptable, not always UCS-4
<John_Boyer> So it's a little unclear what the binary actually is
<klotz> Strings in XPath are Unicode, not UTF/UCS.
<klotz> XPath: Strings consist of a sequence of zero or more characters, where a character is defined as in the XML Recommendation [XML].
<klotz> A single character in XPath thus corresponds to a single Unicode abstract character with a single corresponding Unicode scalar value
<klotz> this is not the same thing as a 16-bit Unicode code value"
<John_Boyer> No
<John_Boyer> Xpath 1.0 says "string (a sequence of UCS characters) rn"
<klotz> Please see http://www.w3.org/TR/xpath#strings
<John_Boyer> The data model doesn't reference XML characters
<John_Boyer> In definition of string in introduction it says sequence of UCS characters
<John_Boyer> So "character data" in string data model definition means "UCS characters"
<klotz> So what's wrong with http://www.w3.org/TR/xpath#strings ?
<John_Boyer> Or, nobody noticed the disconnect
<John_Boyer> Ah, I see, a third definition
<klotz> They use UCS to mean ISO 10646 character set, not to mean UTF-8 encoding.
<klotz> The internal data structure of a string looks to me like it's Unicode code poitns corresponding to legal XML characters which are defined in ISO 10646.
<klotz> 32 bit encoding will give you a lot of 000000410000004200000043
<klotz> Nice chart of Unicode encodings (32 bits of unicode to UCS*, UTF*, ASCII): http://www.azillionmonkeys.com/qed/unicode.html
nick: i'm worried that our decode/encode are now incorrect given the chars not allowed in xml
<klotz> decoding base64/hex should either decode to byte arrays or should take an encoding such as UTF-8 assuming it's encoded byte representations of UTF-8, which then is turned into unicode code points.
john: encode/decode were added
when considering the hmac function as generalizations of some
needed function there
... and digest
... now sounds like we have good reasons not to add them
... proposed (final) resolution -- remove encode/decode
<klotz> +1
<klotz> lost network there it looks like?
<John_Boyer> no you're still here
<John_Boyer> but Steven switched off computer
<John_Boyer> by mistake
RESOLUTION: for issue 146 delete encode/decode
<John_Boyer> adjourning shortly
<John_Boyer> have to remove previous resolution
s/RESOLUTION: for issue 146 maintain the original names for encode/decode to allow for controlling encode/decode from instance data and to add more encodings later//
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/AG/Ag/ Succeeded: s/says/doesn't say/ Succeeded: s/TH/Th/ Succeeded: s/decal/decla/ Succeeded: s/int he/in the/ Succeeded: s/XML/DOM/ Succeeded: s/as/has/ Succeeded: s/string is/string is referring to the/ Succeeded: s/very big/too big of a/ Succeeded: s/mutate/be on mutated/ Succeeded: s/isse/issue/ Succeeded: s/ok/ok in the data model/ Succeeded: s/lots/lots of/ Succeeded: s/iwth/with/ Succeeded: s/nick/john/ Succeeded: s/RESOLUTION: for issue 146 add note on storing non-xml valid data generating validation error on submit, under serialization rules, decode rules// Succeeded: s/ko/ok/ Succeeded: s/beat/leigh beat/ Succeeded: s/serializatoins/serializations/ Succeeded: s/UC/UCS/ WARNING: Bad s/// command: s/RESOLUTION: for issue 146 maintain the original names for encode/decode to allow for controlling encode/decode from instance data and to add more encodings later// Found Scribe: Steven Inferring ScribeNick: Steven Found Scribe: Charlie Inferring ScribeNick: Charlie Scribes: Steven, Charlie ScribeNicks: Steven, Charlie Present: John Charlie Steven Nick Rogelio Rafael MarkB Regrets: Lars MarkS Erik(today) Kenneth Agenda: http://lists.w3.org/Archives/Public/public-forms/2007Sep/0041 Got date from IRC log name: 12 Sep 2007 Guessing minutes URL: http://www.w3.org/2007/09/12-forms-minutes.html People with action items: boyer jboyer john john_boyer johnb johnboyer leigh nick steven[End of scribe.perl diagnostic output]