OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss-x] Intermediate version of generated markdown


Hi Stefan,

thank you for your feedback!

Regarding the editing experience:
Yes, simple safeguards would be convenient! But as a markdown editor is
used to embed XML tags this shouldn't be a hrad drawback. And I do enjoy
seamless processing in my XSL-based tooling! Indeed the 'safeguards' are
a bit bulky (e.g. <var component="dss2-AdditionalKeyInfoType"
element="dss2-AdditionalKeyInfoType.-nonNormative">, but the structure
of markdown does not allow a reliable deduction of the current context.
So I choose to add the component & element attributes.

In 'real life editing' the writer will just fill-in / edit _existing_
safeguarded sections so there will be _no_ need to create it manually.

In case this approach isn't acceptable we could try to shift to more
lightweight safeguards and automatic context derivation. But for now I
would prefer to use the existing approach.

Greetings,

Andreas


> Hi Andreas,
>
> thank you for providing the two versions.
>
> The gren areas are even more riddles to me
> than they were in word era.
>
> Maybe I should better understand where the filler snippets
> are that enter around those safeguarded areas.
>
> It seems that these are in fact a blend of what is in the schema(s)
> and what is mixed into some code I still have to see.
>
> For the editing eperience, I think a simple safeguarde tag like I
> injected in the one sample snippet is more readable and one can
> focus as editor on the text surrounding it instead of writing
> some funny text in few gaps - maybe it is just a feeling that is
> based on a misperception - we seemt to have to find what is more helpful:
>
> Dumb snippet injection from schema and risking inconsistency
> in prose around it because we only see the schema "after merge"
>
> or
>
> Dumb prose insertion and the schema paints nearly the complete
> landscape with prose from some snippets that when to be corrected
> might cause a scavenger hunt.
>
> So I am undecided, but more inclined to look for a more collage
> like solution, that looks for elements in the schema based on markers
> in the prose than as is the other way around.
>
>
> Unfortunately I hae a mandatory "management" course this Monday
> direct after usual office hours until late (9 pm hopefully back home)
> - of course I enjoy the course, but not the conflict ...
>
> So, to ease you guys meeting and reaching quorum, I will
> as usual register my presence.
>
> Please do not forget to copy the chat trace from the "soaphub"
> after the meeting into an email sent to the list.
>
>
> PS: ... feels like tommorow we can hear the bells jingle already
> $ echo "seilf emit" | rev
>
> All the best,
> Stefan
>
> Am 12.11.18 um 22:37 schrieb Andreas Kuehne:
>> Hi all,
>>
>>
>> based on Stefan's markdown version of the core spec 2.0 I applied the
>> 'usual' generation step . See the generated markdown / HTML files
>> attached.
>>
>> To reuse the given setup and the options of the available markdown
>> libraries the most convenient approach is to use the 'var' tag of HTML.
>> In the markdown the user content to be preserved can be inserted between
>> the <var> and </var> in the same way Word offered it in the 'green'
>> sections.
>>
>> Please take a look whether my approach and the results do make sense.
>>
>>
>> Greetings,
>>
>>
>> Andreas
>>
>
>

-- 
Andreas KÃhne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas KÃhne

Company UK Company No: 5218868 Registered in England and Wales 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]