[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [legalxml-econtracts] Re: XHTML 2.0
B. What does the subset you are proposing actually look like? What elements are in it? ie what is the concrete proposal, expressed as a schema (W3c, relax or dtd) I favor deprecating, not removing, elements from whatever schema the W3C issues for XHTML 2.0. It seems to me that the W3C committee is (a) doing the right things so far and (b) open to change. It's a good sign to me that they've create a grammatical paragraph and a recursive container element, meeting two key requirements. It even seems they're thinking of dropping the <hx> elements altogether, so I am hopeful that no deprecation needs to happen at all. C. How does it compare to our other candidate for a range of authoring and other tasks, which we can list and then answer. ie we need to be comfortable that your claim one - that it is adequate - is fair. There is every reason to believe that current X/HTML editing tools, both free and proprietary, will be updated for 2.0. D. Looking down the rest of the structural path from basic clause model -> fleshed out clause model -> complete contract, where is the effort involved? ie how much time will XHTML 2.0 actually save us? i think a significant part of the remaining effort will be common to both XHTML and custom models, since it lies in signature blocks etc, and not so much in the fleshing out part eg span, metadata, table model, images. It's not just how much time is involved with haggling over design for something that we do not need, for something that is met by a more widely-extant standard. I wonder whether trying to standardize an industry-specific paragraph model is a good use of our time in the face of a "good-enough" standard for a paragraph model that is going to be instantly recognized by all major stakeholders we care about. I agree that we need a Signature Module. I also believe we need to develop an Attachment Module and (new) an Instrument Module. I am calling to begin work on these immediately. I see zero gained by having any more calls devoted to our own paragraph model. E. Will XHTML 2.0 be the market behemoth several of us are assuming? Will it sweep all before it, so that no other XML grammars are used for document authoring anymore? If so, why didn't XHTML 1.0 have the same effect. Well, you wrote a good analysis of the inadequacies of XHTML 1.0. These are being fixed in XHTML 2.0, so we now should adjust our direction and priorities. No other viable grammers for document authoring? As a matter of ** standardized document exchange among arms-length parties ** tell me what's the point of a standard that has a different direction than that prevalent in the greater industry? Sure, MS Word can have its own, but you can be sure that it will read XHTML 2.0 documents !!!! You can be sure that MS will update its IE software for 2.0 docs! The Open Office dialect, if it's going to get any traction, must first be supported by the Mozilla platform. However you know that Mozilla is itself focused on implementing W3C standards (faster and better than MS incidentally) so it's going to be implementing XHTML 2.0 support you can be sure well before Open Office. It's up to the parties if they agree on using Open Office or DocBook dialects. They'll probably need to use XSL stylesheets to generate either XHTML or SVG that is displayed by the browser. It's those XSL output streams that are significant and central to any standard for representing a contract recorded on a digital medium, marked up using the XML. The only big issue in my mind is whether any CSS-using, non-XSL using, XML dialect conforms to our standard, and the answer can be yes only if we require that metadata must accompany the XML+CSS file, and that metadata conforms to our requirements. We state that the metadata must contain a map of the structure of the document, but such is only needed when it is something other than an XHTML 2.0 document. Much as I'm interested in moving on to the non-structural stuff, we need to be able to mark up structure before we can sensibly talk about the other stuff ie you've got to walk before you can run. Agreed. XHTML 2.0 provides all the structure we require. So now let's talk about the other stuff. Two final points - (i) how long this all takes is dependent in large measure on having a suitable process. (ii) And if people don't want to discuss the clause model in our regular teleconf, we could schedule a separate one (perhaps for a sub-committee) and do it there. Frankly, there shouldn't need to be a 'long series of calls' though. And as Dave observed, some of the complexity we are dealing with can be seen as belonging to structure, or some other level. So bifurcating will probably make things like metadata harder to handle. I'd like to see the metadata placed into an RDF entity separate from the "structural content" so I don't see why we can't split the group if that's really what's necessary. For my part, I'd likely take a lengthy sabbatical if the group wants to continue with its own clause model.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]