OASIS LegalDocumentML (LegalDocML) TC

  • 1.  Two Questions

    Posted 05-31-2013 06:21
    Hi Fabio,   I have two questions. In both cases, I already agree with the decisions you made. However, in both cases, I've been asked why that decision was made. I want to know your perspective rather than providing my own.   1) Why are element names lowerCamelCase rather than UpperCamelCase. NIEM, and most other international XML Naming and Design guidelines call for UpperCamelCase for element names   2) Why are XLink and XPointer not used? I'm not trying to reopen either of these issues. I just want a clear position statement that I can pass on. -- Grant ____________________________________________________________________ Grant Vergottini Xcential Group, LLC. email: grant.vergottini@xcential.com phone: 858.361.6738


  • 2.  Re: [legaldocml] Two Questions

    Posted 05-31-2013 10:43
    Dear Grant, thank you for the questions. I hope my answer are satisfying. > Hi Fabio, > > I have two questions. In both cases, I already agree with the decisions you made. However, in both cases, I've been asked why that decision was made. I want to know your perspective rather than providing my own. > > 1) Why are element names lowerCamelCase rather than UpperCamelCase. NIEM, and most other international XML Naming and Design guidelines call for UpperCamelCase for element names There are basically two reasons for that: first of all, since most of the element names are composed of one word, UpperCamelCase would have required capitals for them, too, which seemed awkward: <Article>, <Num>, <Section>, <Body>, etc. Second, because we do borrow many very frequent element names from (X)HTML, which uses lower case: we would have had to use <P> instead of <p>, <Table><Tr><Td> instead of <table>,<tr>, <td>, etc. Furthermore, in case you were developing an Akoma Ntoso editor, you could think of using an existing HTML editor for inner-node editing (the editing of the actual text) without modification, while with UpperCamelCase you would have to convert <p>s into <P>s, <b> into <B>s, etc. just for the sake of it. > 2) Why are XLink and XPointer not used? Not one good reason, but several small reasonable reasons: a) we did not need all the fancy link types that XLink makes available, just your old plain simple links. b) one more namespace declaration in the root element, one more XSD Schema file to track and keep updated c) Until XLink 1.1 (2010), xlink:xtype='simple' would have been a REQUIRED attribute in all linking elements. d) xlink:href='XXXX' is longer than href='XXXX' e) XPointer as it currently stands is really useless (and in fact no one is using it). Let me also add this: I was a fervent supporter of the earlier drafts of XPointer, that would have been EXTREMELY useful in many cases around here. Unfortunately, the final version of the XPointer was approved in a severely crippled form, due to the opposition of the DOM group at W3C, who kept insisting that a DOM needs only contain nodes (elements and attributes and whole text nodes), and there was no need for identifying substructures of the text node. Therefore not only the xpointer scheme of the XPointer full language was left out and never approved, but this had ill effects that we feel to this day in the total inconsistency of the various implementations of concepts such as Range and Selection, that, it turns out, are actually useful even though they refer to sub-node entities. Grrrr.... Ciao Fabio > I'm not trying to reopen either of these issues. I just want a clear position statement that I can pass on. > > -- Grant > ____________________________________________________________________ > Grant Vergottini > Xcential Group, LLC. > email: grant.vergottini@xcential.com > phone: 858.361.6738 -- Fabio Vitali Tiger got to hunt, bird got to fly, Dept. of Computer Science Man got to sit and wonder "Why, why, why?' Univ. of Bologna ITALY Tiger got to sleep, bird got to land, phone: +39 051 2094872 Man got to tell himself he understand. e-mail: fabio@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's cradle" http://vitali.web.cs.unibo.it/


  • 3.  Re: [legaldocml] Two Questions

    Posted 05-31-2013 12:19
    Fabio, Thanks for the XPointer explanation. That is a shame. Pat Case of the Library of Congress did a fantastic job of extending XQuery to allow for querying into the text within an element. It is too bad that her work was not extended to XPointer. Perhaps, building XPointer into the browsers with that capability in would show the utility and importance of this to the W3C. Daniel On 5/31/2013 6:43 AM, Fabio Vitali wrote: Dear Grant, thank you for the questions. I hope my answer are satisfying. Hi Fabio, I have two questions. In both cases, I already agree with the decisions you made. However, in both cases, I've been asked why that decision was made. I want to know your perspective rather than providing my own. 1) Why are element names lowerCamelCase rather than UpperCamelCase. NIEM, and most other international XML Naming and Design guidelines call for UpperCamelCase for element names There are basically two reasons for that: first of all, since most of the element names are composed of one word, UpperCamelCase would have required capitals for them, too, which seemed awkward: <Article>, <Num>, <Section>, <Body>, etc. Second, because we do borrow many very frequent element names from (X)HTML, which uses lower case: we would have had to use <P> instead of <p>, <Table><Tr><Td> instead of <table>,<tr>, <td>, etc. Furthermore, in case you were developing an Akoma Ntoso editor, you could think of using an existing HTML editor for inner-node editing (the editing of the actual text) without modification, while with UpperCamelCase you would have to convert <p>s into <P>s, <b> into <B>s, etc. just for the sake of it. 2) Why are XLink and XPointer not used? Not one good reason, but several small reasonable reasons: a) we did not need all the fancy link types that XLink makes available, just your old plain simple links. b) one more namespace declaration in the root element, one more XSD Schema file to track and keep updated c) Until XLink 1.1 (2010), xlink:xtype='simple' would have been a REQUIRED attribute in all linking elements. d) xlink:href='XXXX' is longer than href='XXXX' e) XPointer as it currently stands is really useless (and in fact no one is using it). Let me also add this: I was a fervent supporter of the earlier drafts of XPointer, that would have been EXTREMELY useful in many cases around here. Unfortunately, the final version of the XPointer was approved in a severely crippled form, due to the opposition of the DOM group at W3C, who kept insisting that a DOM needs only contain nodes (elements and attributes and whole text nodes), and there was no need for identifying substructures of the text node. Therefore not only the xpointer scheme of the XPointer full language was left out and never approved, but this had ill effects that we feel to this day in the total inconsistency of the various implementations of concepts such as Range and Selection, that, it turns out, are actually useful even though they refer to sub-node entities. Grrrr.... Ciao Fabio I'm not trying to reopen either of these issues. I just want a clear position statement that I can pass on. -- Grant ____________________________________________________________________ Grant Vergottini Xcential Group, LLC. email: grant.vergottini@xcential.com phone: 858.361.6738 -- Fabio Vitali Tiger got to hunt, bird got to fly, Dept. of Computer Science Man got to sit and wonder "Why, why, why?' Univ. of Bologna ITALY Tiger got to sleep, bird got to land, phone: +39 051 2094872 Man got to tell himself he understand. e-mail: fabio@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's cradle" http://vitali.web.cs.unibo.it/ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php