RE: Proposed extension of data model

There is an interesting subtly here ... and a potentially dangerous back door:

" When the data model results from parsing a MicroXML document"

Fair enough, but consider the flip side.
Suppose the Data Model was the result of parsing something else like say JSON ...
Then all the rules about element and attribute names go away ? We could have  element
names like "A Name With Spaces" ?

Possibly very useful ...
But what do we do to serialize this data model ?
We now allow data models that can come from non uXML sources (fine) but represent data not defined in uXML .   So do we need a whole specification of how to transform the data model that doesnt conform to uXML restrictions back to one that does ?     Are Data Model API's allowed to produce information which is not compliant with uXML itself say names with spaces or colons ?  If then we need to define what extents the data model can differ ... (so upstream processors can handle them).   If not we need to define how API's should treat data models that contain non conformant uXML information.

Maybe I am misunderstanding the proposal here, but if I am understanding it correctly then I would object to such a change in the specs.   If you want a data model that doesnt corespond to the restrictions of uXML itself then define a different data model and call it something else - feel free to say its compatible with the uXML data model in some cases.





-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
www.marklogic.com<http://www.marklogic.com/>


From: James Clark [mailto:jjc@jclark.com]
Sent: Sunday, November 18, 2012 2:33 AM
To: John Cowan
Cc: Michael Sokolov; liam@w3.org; Uche Ogbuji; public-microxml (public-microxml@w3.org)
Subject: Re: Proposed extension of data model

On Sun, Nov 18, 2012 at 10:22 AM, John Cowan <cowan@mercury.ccil.org<mailto:cowan@mercury.ccil.org>> wrote:
James Clark scripsit:

> I would like to change the Data Model section of the spec to separate out
> the aspects of the data model that are purely there as a result of the
> syntactic constraints of MicroXML.

Fair enough.  In that case, I propose that the following text in Section 2
of the current draft:

    A name item is a non-empty string. The first character in the
    string MUST match the production nameStartChar, and any subsequent
    characters MUST match the production nameChar. In addition, a name
    item occurring as a key in an attributes map MUST not be xmlns.

    Any character occurring in the value of an attributes map or as
    a member of a content list MUST match the production char.

be reduced to the first sentence only.

I was thinking of something along the following lines.

Note that this data model is intended to be useful not just for MicroXML. For example, it can also be used to represent XML or HTML documents.
When the data model results from parsing a MicroXML document, it will satisfy the following restrictions:
- the first character in a name item will match the production nameStartChar;
- the second and subsequent characters in a name item will match the production nameChar
- a name item occurring as a key in an attributes map will not be xmlns
- a character occurring in the value of an attributes map or as a member of a content list will match the production char.

James